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.
It allows to specify the resize mode of the paintable inside the
GtkPicture allocation. This also deprecates the keep-aspect-ratio
property.
Fixes#5027.
We were modifying the removed value before passing
it to the items-changed signal, so we always ended
up with removed == 0 in our signal emission, instead
of passing the original value on, as we should.
Pointed out in !4870
The PangoWeight enum agrees with the numeric values
we use here, so we can do this without a switch and
support numeric weight values at the same time.
The width of the left gutter and the height of the top gutter
are now used while computing the child allocations for e.g.
anchors, otherwise - if such a gutter is present - the
widget would be at the wrong position.
Closes#5016
In a list with a visible scrollbar, the scrollbar usually becomes
invisible when the numbers of items is less than the required amount
to scroll. If, however, the list is emptied all at once,
the scrollbar remains. This happens because when there's an empty
list gtk_list_view_size_allocate() returns early before the scrollbar
adjustment is updated.
Given that the list is empty, simply reset the adjustment values
to zero.
Fixes: https://gitlab.gnome.org/GNOME/gtk/-/issues/4370
GtkCheckButton is not derived from GtkToggleButton anymore.
This caused some issues in GtkPrinterOptionWidget which
did not port handling of the button.
Print backends loaded in GtkPrintUnixDialog's load_print_backends()
are not freed later as done in e.g. GtkPageSetupUnixDialog.
This commit destroys and unref those print backends.
Closes#5019
Something like letter-spacing: -0.5px make a lot of
sense. But we were handling the number as integer
somewhere, loosing the fractional part.
Fixes: #5034
Work harder to find examples for char variation
features, and pull the feature labels out of
the font if possible. This lets us show
meaningful names like "Localised @ and & symbols"
instead of "Stylistic Set 7" or even "ss07".
I'm not sure this is API safe, but it is necessary if we want to support
section items and canvas items.
If it's deemed API-unstable, we have to copy this object and deprecate
this one.
This way, we no longer prescribe the use of either GtkListItem or
GtkListItemWidget.
This means we can use it in other places, such as for custom section
header objects or with my Canvas ideas.
With recent updates to GLib, I now see cases where we can hit a state that
has finalized before notify (which will bump the ref count back up). This
is evident in GNOME Text Editor when showing a language submenu from a
popover, and then dismissing the popover and subsequently the tab.
With the previous commit, we at least get a warning like this, which helped
track down the issue.
Gtk-CRITICAL **: gtk_action_observable_unregister_observer: assertion 'GTK_IS_ACTION_OBSERVABLE (observable)' failed
GLib-GObject-CRITICAL **: g_object_ref: assertion '!object_already_finalized' failed
This patch fixes both of those criticals.
Fixes#5009
The menu/action system tends to be incredibly re-entrant, and while fixing
the misuse during finalization cycles should be a priority, this can help
protect just a bit more.
Related #5009
Texts usually want the alignment of each row to match the xalign of
the text itself.
Derive the alignment of the PangoLayout from the xalign property of
the inscription. Because Pango doesn't provide float row alignment,
map left, center and right from the xalign in 1 / 3 steps.
We use "label" just like GtkLabel as the two widgets differ in the way
they are measured, but they should be styled the same.
If it turns out we change our opinion on this for specific cases, we
can add style classes later.
Use set_child_visible(FALSE) on those widgets and don't allocate them.
This should usually be the majority of items, so it's quite a worthwhile
addition.
Idea by Ivan Molodetskikh.
Related: #3334
