Currently, GtkRevealer clips the child if the transition type is
sliding, regardless of whether the animation had already ended. An
example where that is a problem would be in Nautilus: the file
operations popover button is animated on reveal to draw attention, but,
given that the button is in turn stashed inside a revealer with a
sliding animation, things suddenly fall apart.
Instead, use a popup and gdk_surface_move_to_rect.
I have not tried to reproduce all details of the old
positioning logic, but moving the popup above/below
the entry works as before.
In order to make tooltip positioning portable, make use of the
move_to_rect API. Some semantical changes are made, as identical
semantics cannot be implemented using the move-to-rect API.
Primarily the implemented semantics are:
Position the tooltip in the center pixels slightly below (defaults to 4
units below) the tooltipped widget. This is always the case for keyboard
driven tooltips; the case where it tries to avoid the pointer cursor is
not implemented.
For pointer position triggered tooltips, implement the following
additional semantics:
Use the current cursor size to determine the padding used to enlarge the
anchor rectangle. This is to try to avoid the cursor overlapping the
tooltip.
If the anchor rectangle is too tall (meaning if we'd be constrained
and flip on the Y axis, it'd flip too far away from the originally
intended position), rely only on the pointer position to position the
tooltip. The approximate pointer cursor rectangle is used as a anchor
rectangle. Ideally we should use the actual pointer cursor rectangle
(image used as well as hotspot coordinate), but we don't have API to
get that information.
If the anchor rectangle isn't to tall, just make sure the tooltip isn't
too far away from the pointer position on the X axis.
Closes: #134Closes: #432Closes: #574Closes: #579Closes: #878
because filesystem readdir order is indeterministic.
Without this patch, building openSUSE's balsa package
had variations between builds in /usr/share/balsa/icon-theme.cache
When calling PickColor on org.gnome.Shell, we get back an "a{sv}", which
GDBus provides to us as "(a{sv})".
At the minute we're not unpacking this tuple, and so picking fails with
messages like:
GLib-CRITICAL **: 13:38:19.439: g_variant_lookup_value: assertion 'g_variant_is_of_type (dictionary, G_VARIANT_TYPE ("a{s*}")) || g_variant_is_of_type (dictionary, G_VARIANT_TYPE ("a{o*}"))' failed
Gtk-WARNING **: 13:38:19.439: Picking color failed: No color received
Let's unpack it.
The additional assignment to the old result variable just adds an
indirection even though we know the point where we assign it in all
cases. Just pass the values out and return in those cases instead.
Previously, GtkBin was only snapshot'ing its one and only child, but
nowadays it doesn't implement snapshot at all and the default
implementation in GtkWidget just snapshots all child widgets, which is
exactly what the implementation in gtkmodelbutton.c was doing.
Since the original implementation was likely based on GTK+ 3, the change
in default visibility might have not been considered, which results in
all rows suddenly sporting a visible spinner when opening a fresh file
chooser.
Unparenting a GtkListBoxRow can drop its last reference, which
will free its memory. Right after unparenting, though, we were
accessing the row's iter - which assumes that the row is still
alive. This causes a crash when, for example, binding two or
more models to the listbox.
Fix that by storing the iter in a variable, and not trying to
access it after unparenting. After unparenting, the variables
that are potentially garbage were explicitly assigned NULL for
clarity.
Fixes https://gitlab.gnome.org/GNOME/gtk/issues/1258
bindings now treat identifiers and strings the same way.
The only difference was that one allowed lookup of enum/flags by name
while the other didn't and g_warning()ed. Now both work.
Perform scrollbar visibility checks through a motion controller,
always based on GtkScrolledView-relative coordinates. The captured
event handler remains though, for a tiny bit of GDK_SCROLL event
handling.
Use a distinct key controller so we correctly handle navigation
across matches and search cancellation. As the events are forwarded
to the search_window, those need to be pushed down the entry manually.
CSD titlebar are included in the focus-chain. The logic used makes sure that the
initial focus avoids the titlebar, but tabbing around will eventually get there.
This logic fails in case the window has no other focusable widgets apart from
the ones in the header-bar. If this happens keynav focus will be lost. To handle
the above scenario, we need to fallback to focus the header-bar (if any).
Fixes: https://gitlab.gnome.org/GNOME/gnome-software/issues/404
Drop the drag-highlight and drag surfaces. The highlighting
is broken anyway, so just drop it for now. And for dragging
the header button, we can just position it properly, that
works just as well as this reparenting approach.
This fixes a potential leak of a PangoAttrList that is set when chaining
up to the parent get_preedit_string(). We check to see if the attr list
was created and reuse it instead of leaking the previous value.
Remove gtk_menu_popup_for_device() and gtk_menu_popup(), as they cannot
be implemented in a portable manner by all backends. They have been
deprecated for proper alternative APIs for some time, so lets remove
them now before its too late.
While at it, fix the example documentation for mapping a menu.
This is a temporary measure to make the check-icon-names
test not fail in ci. We still have to figure out the best
way to include a core icontheme with GTK+.
GLib master propagates argument types in g_clear_pointer(), which causes
the usual function pointer casts to GDestroyNotify to trip compiler
warnings. Additionally, this commit changes some cleanup functions where
appropriate (wl_data_source_destroy ->
gtk_primary_selection_source_destroy for struct
gtk_primary_selection_source).
Since the function is usually called from GtkWidget::drag-{begin,end} handlers,
taking a GdkDrop does not work, especially given that
::drag-action-requested is emitted without checking the type.
Fixes https://gitlab.gnome.org/GNOME/gtk/issues/1220
The previous attempt at removing configure events entirely
was causing some dialogs not to show up under Wayland.
Presumably due to ordering issues with emitting ::size-change
out of the backend.
Instead, keep configure events in the event queue, but handle
them on the gdk side. This keeps the ordering intact, while
still removing configure events from the api. The dialogs
show up now.
The opaque region is only set when the background color is opaque. So
we need to do something about it when the background color changes.
However, in the case where a size allocation is going to happen, we
already do this update in size_allocate(), so in that case avoid doing
it twice.
Instead of instantly invalidating, we now cache the old render node and
do the update in an idle handler.
While that gives us a 1 frame delay, it avoids all the tricky things
like queueing resizes while resizing or queueing draws while drawing.
The only remaining issue (and a *big* one at that) is that a nested
widget paintable will now cause the widget to snapshot its previous
render node when creating a new one. And that one will snapshot its
previous render node, and that one will...
And nothing so far breaks this recursion.
This is still fallout from the bin_window removal. We aren't moving the
GdkWindow/GdkSurface anymore so we have to account for the scrolling
ourselves.
Since those are widgets and widgets need to be size-allocate'd properly,
we need to queue an allocate, as well as actually add the hadjustment's
value to the column x position.
Fixes#1202
The purpose of a searchbar is to start a search on visible widgets when
a key is pressed. Starting a search on e.g. a stack page that is not
visible at all is not very useful.
... if none of the debug displays have any debug flags set. This way, we
can ignore the first parameter to e.g. GTK_DISPLAY_NOTE, which is
usually a call to gtk_widget_get_display.
Before this patch, gtk_widget_get_display was the slowest part of
gtk_widget_query_size_for_orientation.
The min size on the oriented axis used to come from style props with
default values in the source file, used if the theme did not provide a
min size in CSS. When the style props were removed, so was any notion of
a minimal size for proressbars' main axis, meaning that now progressbars
without expand or any other source of min size were just tiny specks.
The right place to do that was always the theme, so in our themes now,
fix that by copying the old default values for the style properties; see:
https://gitlab.gnome.org/GNOME/gtk/issues/1191#note_259393https://gitlab.gnome.org/GNOME/gtk/blob/gtk-3-24/gtk/gtkprogressbar.c#L92
The result should be the same in that (A) the min size is now what it is
in GTK+ 3 & (B) an app/user can override the theme exactly the same way.
Close https://gitlab.gnome.org/GNOME/gtk/issues/1192
(A) Put a space in "scrolled window" like the other doc comments
(B) Say "i.e." rather than "ie."
(C) Fix grammar from "makes [...] exactly reaches" to "exactly reach"
This is to go along with the newly introduced GdkDrop.
This commit includes the necessary updates to the X11, Wayland
and Broadway backends. Other backends have to be updated separately.
If we check it too early, we will not unset priv->draw_neeeded, which
will then cause queue_draw() calls to not have an effect later. And that
causes changes in opacity to not register.
Closes#1180
Binds this property to the button's label, allowing a model button to
have text with markup.
This will be convenient for buttons like 'Online Accounts <sup>↗</sup>'.
When deciding whether or not to emulate a press event, we're translating
the last event coordinates and mutating the given event structure
unconditionally.
We should modify the newly created GdkEvent copy, since it's what we're
going to use when emitting the press event.
This avoids mutating a constant GdkEvent and global state, and also
avoids a compiler warning.
The idea is that GTK+ 4 will be an epoch, API-wise.
Everything that was around for 4.0 has been there
since the beginning of the epoch and doesn't need
markers.
If the parent get_preedit_string implementation returns a nonnull
zero-length string, then we ignore it, which is almost fine. We have to
free it, though.
Fixes#1174
Expanders used to be 16px high. With the move from the gtk2 rendering
to gtk3 rendering they shrunk to 12px, making them hard to see, because
it's now the icon which is 16px high and the icon contains transparent
borders.
This makes the HighContrast theme use 24px icons instead, to restore
16px expanders. This may expander some containers a bit.
Closes#1046
GtkTextHandle was neglected by whoever removed the ::draw signal,
leaving it entirely broken. Update to using GtkGizmo so we can
implement snapshot of text handles.
Input has received a revamp too, handling is done through a
GtkGestureDrag and coordinate calculations simplified by storing
the delta to the hotspot on ::begin instead of ::update, as this
value is constant throughout the gesture. Widget state management
on crossing events happens implicitly, so no longer needs to be
done here.
Last but not least, CSS has also been updated so handles are
rendered at the correct size and proportion, and with the padding
that code expects of it.
Set up a gesture on the sidebar rows to detect pointer clicks on
it. The row DnD management has been moved to the row widget itself,
it makes more sense even if the drag is began from the sidebar widget.
We still need a drag gesture both on front (capture) and back (bubble)
to handle dragging from both the GtkWindow widget and chrome in the
headerbar. But we can do it through 2 drag gestures, instead of special
event handling code.
This has been broken since we switched key event delivery to follow
the same semantics than pointer/touch. There, GTK+ grabs will influence
the topmost widget during event delivery, rendering the toplevel
unable to handle key navigation. The toplevel must handle those key
events in an explicit manner then.
We don't render the keyboard focus rectangle yet, but I assume that's
something else.
Use an event controller on GtkFontChooserDialog, a nice side effect
is that we can use gtk_event_controller_key_forward() and
gtk_search_entry_set_key_capture_widget() instead of passing events
around for dialog search.
Instead of doing all handling manually in the ::event vfunc,
set up drag/multipress gestures on icon images, and implement
emission of ::icon-press/release and DnD there.
As a side effect, the GdkEvent field in ::icon-press/release
signals has been dropped. Callers that might be interested on it
may still use gtk_get_current_event*().
This isn't really necessary, if keyboard focus forcibly goes somewhere
else we will get ::grab-notify, which is sufficient to deactivate the
button again.
Selected rows in tree views in HighContrast have a background colour the
same or nearly as the normal text colour, so we cannot let entries in
such rows have transparent backgrounds, or the text inside the entry
becomes nearly or totally impossible to see.
Dodge this by giving entry.flat inside treeview and with :focus the
$base_color, which is different from the text & so lets that be seen.
https://gitlab.gnome.org/GNOME/gtk/merge_requests/125
The else case was wrongly resetting the accessible description on the
primary icon, which might not exist and can therefore cause a crash.
https://gitlab.gnome.org/GNOME/gtk/issues/1160
The claimed status check should happen after ::end is emitted,
as the gesture may deny the sequence that much late. In this
case the event should keep propagating.
https://gitlab.gnome.org/GNOME/gtk/issues/1159Closes: #1159
We are poking again into the event propagation machinery, which
expects events in toplevel coordinates. Since we can't fetch the
original event back at this point, translate the coordinates
back to the toplevel so the emulated press ends up in the right
place.
https://gitlab.gnome.org/GNOME/gtk/issues/1159Closes: #1159
In particular, this patch removes:
gdk_surface_get_events()
gdk_surface_set_events()
gdk_surface_get_device_events()
gdk_surface_set_device_events()
Event masks so far still exist for grabs.
