The way we explicitly set the font on the entry
conflicts with the placeholder text styling. But the
entry isn't normally empty, so placeholder text is
not that important here. Remove it and use a tooltip
instead.
When reordering notebook tabs, updating the sensitivity state of the
arrow buttons is necessary if the tab is moved to the beginning or
end of the tab list.
When notebook tabs are reorderable, pressing the notebook arrow buttons to
change the active tab results in tabs reordering unexpectedly.
Claim the event sequence after pressing an arrow button to avoid conflicts
with the motion/drag gesture used for reordering.
A typo resulted in the tab container widget being retrieved instead of
the tab widget. If an adjacent action widget was present, an infinite
loop occurred when switching tabs while a screen reader was enabled.
When we collapse a node, we clear out the children,
but we were not disconnecting the signal handler on
the child listmodel, leading to bad outcomes when
that model is persistent and changing.
Fixes: #4595
As I propose to deprecate gdk_win32_surface_get_impl_hwnd() next,
replace it with the alternative.
The main difference between the two functions is that
gdk_win32_surface_get_impl_hwnd() fails gracefully by returning NULL if
the surface is not of the win32 implementation.
All the surfaces should be native surfaces here, and the existing code
doesn't seem to deal with NULL case anyway.
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
We were disabling the insert-emoji action when the
no-emoji input hint is set, but the Ctrl-. shortcut
was bypassing the action and kept working. Make
the shortcut activate the action instead.
Fixes: #5123
When some of the Emoji have been filtered out by
a search term, arrow keynav would behave oddly and
get stuck in invisible sections. Fix this by ignoring
any filtered out children when moving between
sections for arrow keynav.
Fixes: #5076
Currently, the wayland IM context sends zwp_text_input_v3.commit from
a number of places, and some of them with partial data. In order to
make client state updates "atomic" and complete, make the communication
happen over an unified notify_im_change() function that happens on
a narrower set of circumstances:
- The GtkIMContext is reset
- The GtkIMContext is just focused
- The gesture to invoke the OSK is triggered
- The IM context is reacting to changes coming from the compositor
Notably, setting the cursor location or the surrounding text do not try
to commit state on their own, and now will be flushed with the corresponding
IM update or reset. But also, these requests won't be prevented from
happening individually on serial mismatch, instead it will be the whole
state commit which is held off.
With these changes in place, all client-side updates are notified
atomically to the compositor under a single .commit request.
Fixes: https://gitlab.gnome.org/GNOME/gtk/-/issues/5106
Fixes: https://gitlab.gnome.org/GNOME/gtk/-/issues/5105
During text widget manipulation (inserting or deleting text via keyboard)
the IM context is reset somewhat early, before the actual change took place.
This makes IM lag behind in terms of surrounding text and cursor position.
Shuffle these IM reset calls so that they happen after the changes, and
ensure that the IM is actually reset, since that is currently toggled on
a pretty narrow set of circumstances.
Also, fix a bug during GtkEventControllerKey::im-update where the condition
on cursor position editability to reset the IM context was inverted.
During text widget manipulation (inserting or deleting text via keyboard)
the IM context is reset somewhat early, before the actual change took place.
This makes IM lag behind in terms of surrounding text and cursor position.
Shuffle these IM reset calls so that they happen after the changes, and
ensure that the IM is actually reset, since that is currently toggled on
a pretty narrow set of circumstances.
We need to free the queued context list in dispose
if we didn't get to register the contexts, and we also
need to free the list properly when we do get to
register them.
This showed up in valgrind as leaked GList structs.
When GTK_EVENT_CONTROLLER_SCROLL_DISCRETE is set, accumulate deltas also
for mouse scroll so a high-resolution mouse wheel click behaves in the
in the same manner as a low-resolution mouse wheel click.
Instead of calculating the discrete scroll deltas in
GtkEventControllerScroll, move that code to the event constructor and
access the precalculated values using gdk_scroll_event_get_deltas.
Refactor, no functional changes.
gtk_tree_view_top_row_to_dy, which is called from GtkTreeView's
size_allocate function, changes the adjustment value. Since this
conflicts with the animation when changing the active row, bail
out until the animation is finished.
Fixes#4550
When a GtkTreeView scrolled horizontally, it was not possible to
select rows outside the initial area due to an erroneous comparison
between widget and bin window coordinates.
Original change to widget coordinates occurred in commit
a0de570e47
Commit adba0b97 fixed missed pointer crossings by using a helper function that
was already present and looked like did everything that was needed. However
this function was oriented to keyboard focus and it also did update the related
widget state. Doing these changes on pointer-based crossing was misuse, and
could cause weird interactions with keyboard focus management.
Fix this by using gtkmain.c gtk_synthesize_crossing_event() that is in fact
oriented to pointers.
Fixes: adba0b97 (gtkwindow: Synthesize pointer crossing events on state changes)
Closes: https://gitlab.gnome.org/GNOME/gtk/-/issues/5094
Instead of passing an event and figuring out coordinates from it, pass
directly the toplevel coordinates so that we can use this outside event
handling.
All callers have been updated to pass the coordinates, in practical effects
they were already based on the GtkNative.
The inner loop in gtk_paned_set_focus_child() tries to find the
topmost GtkPaned, however, if the `w` variable ends up becoming
NULL after bubbling up the entire GtkWidget hierarchy, this loop
never breaks.
Check for NULL in this loop.
Closes https://gitlab.gnome.org/GNOME/gtk/-/issues/5094
c68247f63b introduced a scroll multiplier,
intended to be significantly lower than the GTK 4.6 behavior but higher
than 1. However, it was _higher_ than 4.6, since 4.6 also had a permanent
1/10 multiplier in GDK, so the cited multiplier values were really 6.4 and
9.7.
We may have situations where velocity is 0/0, but are overshooting. Places where
this happens are mouse wheels, and continuous scroll that ended up still before
finish. In this situation we also want to run the animation for overshoot, so
check for the corresponding axes to also set up the kinetic scroll helper.
Closes: https://gitlab.gnome.org/GNOME/gtk/-/issues/4784
The expected configurability is not going to arrive yet from compositors, and
it is precipitate for GTK to gain any configurability. We do know a factor of 1
feels way too slow, and we do know a factor of page_size * pow (2 / 3) feels way
way too fast.
With the previous multiplier, gtk4-demo at its default size had a vertical textview
factor of 64.332901, and maximized on a 1920x1080 screen a factor of 97.585365.
Pick a magic multiplier that is both significantly below these values and above 1,
and stick to it.
Future work will add the configurability of smooth scroll events where it belongs.
At that point this commit may be reverted so we don't pile up on magic numbers again.
Related: https://gitlab.gnome.org/GNOME/gtk/-/issues/4793
When widgets go mapped/unmapped, we repick but don't generate crossing
events. Since there could be stateful controllers that use those in
the previously picked widget (e.g. GtkEventControllerMotion), skipping
those breaks their state.
Ensure to send the relevant crossing events on every situation that
changes the pointer focus, so these controllers get a fair opportunity
to undo their state.
Closes: https://gitlab.gnome.org/GNOME/gtk/-/issues/2877
Following what was done for pinch/swipe events, give hold gestures their
own distinct sequence as well. Without this it was NULL, which was already
distinct to other touchpad gestures.
This delaying of the cancel event was made to avoid intermediate cancellation
for >=2fg hold gestures followed by pinch/swipe gestures, and it worked as
long as everything was considered to have the same sequence.
Since each pinch/swipe pointer gesture now gets its own sequence, this no
longer applies, nor works. This results in zoom/rotate/swipe gestures being
stuck since the sequence for the touchpad events changes mid-gesture.
Sticking to this pattern of giving touchpad gestures their own sequence,
these hold events cannot be assumed to coalesce with other touchpad gestures,
it is better to let it propagate altogether so that both the hold gesture
and the incoming gesture trigger coherent begin and end/cancel phases.
In the worst case, this results in "::begin, ::cancel, ::begin , ..." before
triggering a touchpad gesture, but the extra begin/cancel ought to be a safe
no-op in widgets.
Closes: https://gitlab.gnome.org/GNOME/gtk/-/issues/5003
The textbuffer test is calling into a function defined by the AT-SPI
accessibility backend. As of commit 4ddf1b70 we only build and run the
test on Linux, but the function in question isn't really
accessibility-related: it's just a serialization function.
If gtk_builder_expose_object() is called twice with the same name, it will
result in a g_critical(). This improves that situation by checking for the
object before exposing additional times.
This turns out to be handy in situations where templates are expanded
multiple times, such as application-side implementations of UI merging.
Rubberband does not work when initiated past the last row
(warning is printed "Could not start rubberbanding: No item).
Clamp y at the max height of the widgets in the listview
Rubberband does not work when initiated past the last row
(warning is printed "Could not start rubberbanding: No item).
Clamp y at the max height of the widgets in the gridview
Fixes: #3462
The function gtk_grid_view_get_items_in_rect() erroneously calculates
columns less than 0 and greater than n_columns when the user attempts
to rubberband all the way to the left or right respectively. This
causes the rubberband to persistent and creates unexpected behavior.
Limit the rows to a minimum of 0 and maximum of n_columns - 1.
Fixes: https://gitlab.gnome.org/GNOME/gtk/-/issues/3445
There's a list user_widgets that contains all of the entries and
selections during authentication. This is only freed upon
finalizing the GtkMountOperation. It's possible (and true for the
GVFS SMB implementation) that a MountOperation can have the
gtk_mount_operation_ask_password_do_gtk () function called multiple
times (i.e. bad password). The user_widgets list grows with now
invalid pointers to old widgets (causing unexpected behavior and
seg faults).
Free the user_widgets list upon dialog destruction, we don't need it
anymore.
Fixes: https://gitlab.gnome.org/GNOME/gtk/-/issues/5059
Fixes: https://gitlab.gnome.org/GNOME/gtk/-/issues/5058
It is already explicitly assumed that anonymous authentication will
be used when available, but it is not clear to the user since neither
of the check buttons are selected. Select the Anonymous check button
by default.
When computing a transform value, there is nothing
to do, but we still need to copy the matrix from
src to dest, since it depends on the other transforms
in the array whether we are using the src or the
dest in the end.
This fixes cases like
-gtk-icon-transform: perspective(100px) matrix(1,2,...);
which would otherwise end up with a zero matrix.
Functions already exist for providing a unique drag action for gdk_drop_finish().
Reuse these functions in the drag_enter/motion callbacks, since they require
a unique action as the return value.
Fixes#3187
For default popover arrow position and default height-for-width layout mode,
natural_width is calculated first with for_size=-1 and orientation=HORIZONTAL,
at the end of gtk_popover_measure() natural_width won't be added with tail_height.
Then to measure with for_size=natural_width and orientation=VERTICAL, obviously
for_size shouldn't be substract with tail_height.
The wrong logic will force content in popover gets less width and then text labels
in popover may get wrapped unnecessarily.
The new content-fit property was wrongly suggesting to manually set
widgets' overflow property, but that property is not really intended to
be set by external code. This commit removes those suggestions and
directly set picture's overflow to be hidden.
