Since we now have a widget whenever we query tooltips, we can as well
get the events target_widget if we have an event (which is what we do
when coming from gtkmain.c). This keeps us from searching the entire
widget hierarchy for the target event even though we've already done
that for pointing events in gtkmain.c
This reduced the work done in gtk_tooltip_handle_event in normal motion
events to basically nothing since we already did all the heavy lifting
when handling the pointing event in gtkmain.c
As stated by the documentation, this should be called when a widget gets
updated, but in that case, one can equally use
gtk_widget_trigger_tooltip_query.
If the text style changes, or the display settings do, we need to update
the state labels to ensure that the glyphs are available in the font
we're using.
The entire color scale hack is still done in GtkRange, which draws the
color scale in the range gizmo. So, to correctly redraw the color scale
when setting a new color, we need to redraw the proper widget and that's
the trough widget.
Fixes#1453
Instead of recording the way up from the target widget to the grab
widget (or toplevel) and then walking that path upwards, just walk the
parent chain and look at the cursor.
Most of the time, the GtkSnapshot objects we create while snapshotting
widgets don't end up containing all that many nodes or states in their
respective node or state stack. This undermines the amortized allocation
behavior of the G(Ptr)Array we use for the stacks. So instead, use the
(until now unused) parent_snapshot GtkSnapshot* passed to
gtk_widget_create_render_node and reuse its node and state stack.
We do not avoid allocating a new GtkSnapshot object, but we do avoid
allocating a ton of G(Ptr)Array objects and we also avoid realloc'ing
their storage.
Even though the IEC power glyphs are part of Unicode 9.0 (released in
2016) not all fonts have them.
To avoid showing the hexbox of doom when the system font does not have
the glyphs we'd like to use, add a fallback pair, using the old glyphs
we suggested when the labels were translatable.
The refactoring of automatically updating tree->root when setting a
node's parent works very well - unless all nodes get removed and no
node's parent got updated.
The tree is not needed to walk around the nodes.
It is however still needed for anything that requires modifying the
tree.
There is no immediate benefit in changing this API, but there might be
situations in the future where we can avoid looking up the tree when we
just want to check some details about the node.
Store a link to the tree in the root node. This allows looking up the
tree in O(log N) from the node without any extra memory usage.
This is useful because code can just store a pointer to the node and
doesn't need to keep the tree pointer around. And that can (for large
trees) save quite a bit of memory.
Searching through the tree is too specific to use a general function.
All the existing code just copies and slightly adapts the same 20 lines
instead, so there's no reason to keep the complicated API.
Considering the operations that some of the rendernode constructors
do, nodes with width or height 0 (or both of course) are very well
possible. This would break in the rendernodepaintable when adding a
transform, which divides by width/height of the rendernode.
This can happen whenever the ::activate-link handler sets different
markup on the label, causing all links to be recreated. In this case,
the GtkLabelLink* passed to emit_activate_link is garbage after the
g_signal_emit call and we shouldn't try to do anything with it.
Fixes#1498
Unicode 9.0 introduced glyps for the "on" and "off" power states, in the
form of:
- U+23FD POWER ON SYMBOL, or ⏽
- U+2B58 HEAVY CIRCLE, or ⭘
With `HEAVY CIRCLE` as "power off symbol" selected to avoid adding yet
another circle to the standard.
Since we moved GtkSwitch to always show glyphs instead of (translatable)
strings, asking the localisation teams to either come up with a suitable
short string to replace the English "ON" and "OFF", or to fall back to
Unicode glyphs, we should ensure we're using the appropriate symbols to
begin with.
See also: gtk!503 for the corresponding gtk-3-24 change.
Signal emittion was added in 6f857f87dc commit and it seems that
this is only place where selected_row is set after emitting signal.
Because of this gtk_list_box_get_selected_row currently returns NULL
as selected row if selection mode is set to GTK_SELECTION_BROWSE.
The target position is irrelevant for determining if the child should be
visible. When the current position is 0, it needs to be hidden, period.
Fixes#1355
The previous fixes made it unnecessary to hardcode IM modules for
different display types. The code now automatically skips system IM
modules for other displays.
The code would technically allow loading the xim module when X11 support
was not compiled in.
This is probably an artificial concern, because it's pretty hard to
compile XIM support without X11 support, but it makes the code clearer,
so there we go.
Context IDs are dependant on the display - both because displays can use
different backends, but also because changing the GtkSetting is a
per-display operation.
So just remove the cache.
If it turns out we need a per-display cache, we can add one to
GtkSettings.
Calling the accessibility function `grab_focus()` on a `GtkCell` under
Wayland will cause the client to crash.
This is another case of `gdk_x11_get_server_time()` being called
regardless of the actual windowing backend used.
Closes: https://gitlab.gnome.org/GNOME/gtk/issues/1507
So it's able to operate properly with the DnD gesture set by
gtk_drag_source_set(). We usually just react on button release,
that's the right time to claim the gesture.
Closes: https://gitlab.gnome.org/GNOME/gtk/issues/1557
I was stuck in an X session and noticed that my resize corners
all got east or north cursors. It turns out that gnome-shell
does not properly advertise support for edge constraints under X11,
and the absence of that makes the code for determining the edge
under the cursor misbehave.
This change should fix that.
g-ir-scanner incorrectly evaluates macro definition that include
references to other macro definitions. Provide a correct value as an
annotation.
Differences in generated gir files:
```diff
@@ -19017 +19017 @@
- <constant name="PRIORITY_REDRAW" value="20" c:type="GDK_PRIORITY_REDRAW">
+ <constant name="PRIORITY_REDRAW" value="120" c:type="GDK_PRIORITY_REDRAW">
@@ -74229,3 +74229,3 @@
</constant>
- <constant name="PRIORITY_RESIZE" value="10" c:type="GTK_PRIORITY_RESIZE">
+ <constant name="PRIORITY_RESIZE" value="110" c:type="GTK_PRIORITY_RESIZE">
<doc xml:space="preserve">Use this priority for functionality related to size allocation.
@@ -106786,3 +106786,3 @@
<constant name="TEXT_VIEW_PRIORITY_VALIDATE"
- value="5"
+ value="125"
c:type="GTK_TEXT_VIEW_PRIORITY_VALIDATE">
```
See !472
If the revealer is told do animate and then unrealize itself, we do
(correctly) stop the animation, but used to do a shortcut where we
just set the target state as current.
Other things are dependent on the animation properly finishing though,
like the contained widget child visibility. This may lead to inconsistent
state where gtk_revealer_get_child_revealed() returns TRUE but the child
widget is unmapped, or vice-versa.
Fully finish the animation here, so the child state is coherent the next
time the revealer is mapped. We can also skip notifying on the property
since it will be handled by gtk_revealer_set_position().
Before this patch, imwayland would assume that text-input enter and leave events follow the general (wl_keyboard) focus, and was unable to handle the situation where they would not be provided at the same time.
Fixes terminal emulator misbehaviour as outlined in https://gitlab.gnome.org/GNOME/gtk/issues/1316, which was introduced in 49b17e6c. The original commit cleared preedit text by setting it to an empty string, which still counted as existing preedit. The fix sets preedit string to null, which is correctly understood as not present.
There may be situations where this might get called while the
currently focused context just went away (eg. after setting the
text widget unsensitive).
Closes: #1317
Do not call _gtk_widget_captured_event(), in propagate_event_down(), or
gtk_widget_event(), in propagate_event_up(), when the widget has been
unrealized.
iter_init_common() is used on uninitialized GtkTextIter, and since neither it
nor its callers initiliaze its padding fields, they contain garbage.
This is a problem for Go - which checks that structs passed to C functions do
not contain pointers to Go-allocated memory - when the garbage happens to be
such a pointer. Although Go zero-fills all GtkTextIter that it allocates, this
does not help when GTK functions such as insert_pixbuf_or_widget_segment called
for gtk_text_buffer_create_child_anchor copy garbage from their stack-allocated
GtkTextIter into a clean iter. To work around this a GtkTextIter has to be
discraded after use in text buffer anchor inserting functions:
https://github.com/gotk3/gotk3/pull/307
We display a list of supported protocols in the server_addresses_popover.
However, this curated list contains protocols which may or may not be
available, depending on the respective gvfs backend being installed.
So, populate the list only with protocols which are available.
https://gitlab.gnome.org/GNOME/gtk/issues/1476
When the user types an address with a schema that is not supported,
the Connect button doesn't become sensitive, but there is no visible
feedback at all.
This feels unresponsive and leaves the user clueless.
While it doesn't help explain why the address doesn't work, this will
provide a hint that the input was acknowledged but doesn't work.
https://gitlab.gnome.org/GNOME/gtk/issues/1476
Issue #1495 showed that the docs of GtkGrid retain outdated implications
that (as was once, but is no longer, the case) it is intended to replace
GtkBox, by discussing HfW and widget properties in a way that suggests
GtkBox can't handle them. But of course it does, and it's preferable for
simple single-row/column cases. Worse, we said GtkGrid “provides exactly
the same functionality” for the latter case, but the original point of
that Issues was that it doesn’t, at least for CSS positional selectors!
Box:
• Use an actually meaningful @Short_description.
• Remove unhelpful @See_also references to unrelated containers.
• Remove references to “rectangular area”: it might be another shape
via CSS, or “rectangular” might falsely imply 2 dimensions of children.
• Mention Orientable:orientation.
• Emphasise usefulness of :[hv]align for allocating in the other axis.
• Don’t say that Grid “provides exactly the same functionality” for a
single row or column, since (A) it is overkill for that case and (B)
said Issue proved that it *doesn’t* for CSS child order, for example.
Grid:
• Don’t dwell on widget properties and height-for-width in a way that
wrongly implies that Box can’t handle those (or Grid can better). In
fact, just get rid of that bit altogether: Box handles them fine, and
such wording was only needed years ago for migration from GTK+ 2 to 3.
• Point to GtkBox as being preferred for the simple row/column use case.
Append a variation selector to the Emoji sequences,
to force Emoji presentation. Without this, some
Emoji come out with text presentation by default.
Closes: Pango #334
- step back on toning down the borders. Flatness !> legibility.
- darker active state for light
- draw gradinets from bottom up, to keep px sized shading regardless
of button size.
Increase the visibility of the box-shadow for menus
Introduce a border-radius variable for menus
Use this variable for all corners of menus except top for the top menus
We wrap SVG data from icons within another SVG with extra styling
information. The wrapped SVG may contain characters that cannot be
part of a data: URL (https://fetch.spec.whatwg.org/#data-urls).
Librsvg 2.45 got more strict in its parsing of data: URLs; whereas
previously it ignored '#' characters in them, now it considers them to
be the start of a fragment identifier, which is not allowed in data:
URLs anyway.
To avoid unallowed characters, we now create a data: URL with a
base-64 encoded SVG.
Fixes https://gitlab.gnome.org/GNOME/gtk/issues/1471
This is important when the target widget of an event is not the one that
would otherwise receive the gesture. For example, the GtkSwitch
implementation currently attaches a pan gesture to the switch itself,
but the target widget below the pointer might be the switch slider or
label.
See #1465
It is permissable to remove a widget using gtk_container_remove from the
gtk_container_foreach callback handler. Document this fact to make it
more discoverable.
Fixes#1461
Currently, gtk_event_controller_scroll_handle_event() always returns
TRUE if it is handled, which stops the propagation of the event. If
there’s a single GtkEventControllerScroll in the widget hierarchy, that
means that no others will run, depending on the propagation phase. In
Nautilus, this can be observed when adding a scroll controller to the
GtkScrolledWindow (ctrl-scrolling controls the zoom level) - either the
scrolling or the zooming breaks.
Fixes https://gitlab.gnome.org/GNOME/gtk/issues/45
Gives the same background color to all separators descending from a
title bar than to its direct childrens.
This prevents separators which are in a titlebar but not direct children
from the widget with the titlebar style class from being almost
transparent and hence it prevent them from revealing the clear color of
the window's titlebar (black).
https://gitlab.gnome.org/GNOME/gtk/issues/1231
This is better than nothing at all. The wording is taken from Carlos's
commit message when he added this shortly before 3.12 (but skip Since).
Skip the bit from his commit message explaining what this replaced; we
don't need to say all the less good things our convenience API replaces.
This is the excellent explanation from Emmanuele at
https://gitlab.gnome.org/GNOME/gtk/merge_requests/402#note_361210:
"
Every time you instantiate a type, the instance_init() function is called for each
parent type T_p of your type T; to preserve invariants, the class pointer inside
the instance data is set to the parent type before each invocation, until you hit
your type T. This means that calling GET_CLASS() inside an instance_init() function
will give you a pointer to the class vtable for the parent type T_p while you're
iterating over parent types. What if you want to access the actual class vtable of
the type T, though? Well, you can because the actual signature of instance_init() is:
void (* GInstanceInitFunc) (GTypeInstance *instance, gpointer g_class);
i.e. all instance_init() functions get passed the instance they are initialising
and the class vtable of the real type you're instantiating.
This is how GtkToolButton works: it "peeks ahead" at instance initialisation time,
to use the button_type class field of the actual type you're instantiating,
and calls g_object_new() with it to store the resulting object in its own private
data structure.
This whole contrived mechanism is needed to allow out-of-tree tool buttons to just
set the button type on their class init, and have their parent class create the
button they want, instead of asking all tool buttons to do this themselves and have
a virtual function called get_button() for GtkToolButton to call whenever it needs
to operate on the button instance.
Now we're coming to a close: we cannot use the G_DEFINE_TYPE macro because the
instance_init() function it creates internally will not pass the class pointer
to your custom instance_init(). Since we cannot use G_DEFINE_TYPE, we also cannot use
G_ADD_PRIVATE either.
This is the reason why, when I ported GTK 3 to the new private instance data structure
macros, I left GtkToolButton alone. I should have left a comment there, because @matthiasc
tried doing that as well, and then had to revert it in commit 1c4a7bd5. So: my bad,
sorry about that.
If we want to drop the G_TYPE_INSTANCE_GET_PRIVATE and the g_type_class_add_private() calls,
we cannot use G_DEFINE_TYPE, but what we can do is unrolling what the macros do themselves:
- add a global GtkToolButton_private_offset variable
- add a static inline gtk_tool_button_get_instance_private() that does return
(G_STRUCT_MEMBER_P (self, GtkToolButton_private_offset));
- call g_type_add_instance_private (g_define_type_id, sizeof (GtkToolButtonPrivate)) inside
gtk_tool_button_get_type() and store the result in GtkToolButton_private_offset
- replace g_type_class_add_private() inside gtk_tool_button_class_init() with
g_type_class_adjust_private_offset (klass, &GtkToolButton_private_offset)
"
and use 150 as natural-width.
Currently there's no way for a GtkEntry to be less
than 150px wide (apart from using "width-chars" property),
this is too much for a default minimum-width, an app
developer may need to have a shorter GtkEntry, for example
when the UI it's been shrunk by the user (see [1]) or when
you want to match the size of another widget (which is less
than 150px) see [2] for Evince bug on using
gtk_combo_box_new_with_model_and_entry() for PDF forms where
GtkEntry of ComboBox is too wide and doesn't match the combo
list width.
Using "width-chars" property may be a workaround to obtain
a short minimum-width for the entry, but is not a proper
solution for the mentioned cases as you may not know how
short your GtkEntry will be, or the fact that using "chars"
as a width unit is not pixel accurate.
Curious note: the commit that introduced the GtkEntry
minimum-width to be 150px is from 20 years ago, see
https://bit.ly/2ySEfK4
[1] This change was already suggested by Benjamin Otte
in a blog comment https://bit.ly/2J96wRo
[2] Fixes issue evince#1002
- Selection mode does not get the special devel styling.
- removed teh last-child() selector for it doesn't work anymore.
Better style all section of the headerbar than none. Proper fix pending.
https://source.puri.sm/Librem5/libhandy/issues/57
This was noticed in Firefox and demonstrated using a GtkBuilder ui file.
buildable_add_child() calls set_tab_label(), but the latter did nothing
to update the menu_label corresponding to that tab with the new text.
Using Builder to populate the tab child, only tabs other than last got
the right non-default labels, and even that was mostly coincidental, as
adding the main child called update_labels() via real_insert_page(), so
it took effect when the 2nd last main child is added, updating the rest
but leaving the last with the default label, not that given in Builder.
Fix by factoring out the code from child_reordered() to a new helper
menu_item_recreate() and calling that in set_tab_label(), so that
whenever the tab_label is updated, so is its corresponding menu_label.
This fixes the reported case and presumably others that we could write.
fixes https://gitlab.gnome.org/GNOME/gtk/issues/1397
Commit 64a489ad inadvertently introduced a regression that broke Korean
text input because the changes there resulted that only the last input
string that we have from ImmGetCompositionStringW() for each time the
commit signal is emitted is kept, and also as a result the final Korean
character that is input by hitting space is also lost as a result, as we
didn't check for whether we are done with preediting.
Fix these issues by doing the following when we receive the
WM_IME_COMPOSITION message with GCS_RESULTSTR from Windows:
-Do not emit the commit signal during WM_IME_ENDCOMPOSITION, and...
-Emit the commit signal anyways, as we did before c255ba68, however...
-We still save up the string to commit, because we need to re-compute
the cursor position when we do ->get_preedit_string(), which needs to
take the GCS_RESULTSTR string we get from WM_IME_COMPOSITION into
account as well, so that we avoid getting the Pango criticals that
occur during Chinese (and most likely Japanese) input as the cursor
position is out-of-range.
Fixes issue #1350.
The previous type was a pointer to a pointer, which seems to be a copy-paste
error from GtkBuildable.custom_tag_start which is an out parameter. It was
always cast in use so this is an API break, but not an ABI one.
The gtk_stack_snapshot_slide() function dereferences the
last_visible_child pointer without proper != NULL ckeck. This might
result in NULL pointer dereference and crash if last_visible_child is
invalid.
Add a != NULL check before dereferencing the pointer.
There’s a short-path done for focus rectangles, but it can be taken in other conditions, and then fail occasionally to render a dashed line if the border-width is too big.
Variable, added, would be a garbage value if model is NULL and
the following code, if condition, use the uninitialized variable.
A side effect could be occurred by that.
To avoid, the variable is initialized to zero.
After removing elements, there were a few cases where the tree wasn't
properly balanced which could further down violate assumptions about the
layout.
Attached is the original testcase that triggered it. I didn't bother
simplifying it.
Up until now when allocating the child it only used the natural size
while the measuring also used the minimum size, resulting in a clipped
child when animating if the child had different minimum size and
natural size. This was an obvious case when using labels that had
ellipsization.
This commit gives full allocation to the child by inverting the size
the revealer reduces from its animation progress.
Code done by Benjamin Otte.
Closes: https://gitlab.gnome.org/GNOME/gtk/issues/635
The complexity with model items vs row items is really confusing. Add to
that treelistmodel position vs child model position vs parent position,
and you're so confused, even the best naming can't help.
And once you're there, consider passthrough vs non-passthrough...
When passthrough is enabled, it should return the GType
of the child GListModels; when disabled, it should be
GTK_TYPE_TREE_LIST_ROW.
The conditions are inverted however, causing a few
warnings to trigger.
Fix that by returning the correct GType.
