This gives us marks to track the duration of processing certain types of
GdkEvent. It also provides some basic struct information in cases where
having that information would likely be useful for debugging.
Page ranges entry can now be focused directly, and will automatically
select the page ranges button when doing so.
This avoids the sometimes counter-intuitive previous behavior where the
entry was automatically focused when toggling the radio button, but the
user may still find themselves clicking uselessly in the text entry
because they scheduled it in their mental model.
Instead, use a new title style class to let
themes influence title formatting. Note that
the theme style will be overridden if the
application uses markup for presentation,
such as <b> or <i>.
Port this from ::populate-popup to the new context
menu api. At the same time, fix some parts of the demo
that were broken since it was changed to use GtkStearchEntry.
Drop the ::populate-popup signal and implement
the new context menu api. Things are a bit more
complicated here, since we have different menus
on links and selectable text.
Menus traditionally don't have separate
hover and focus locations. Make the same
change here that we already did for
popover menubars: Track the active item
and set its selected state. Both keynav
and mouse change the active item.
The Wayland backend has a hack to work around
a race with popover mapping: If the surface size
changes before the initial configure, we hide and
show the surface. Unfortunately, the code was doing
this in a way that is externally observable (by
listening for surface state changes), and popovers
were observing it and hiding themselves in response.
Avoid this by not going through the GDK frontend
code for this.
This solves issues with parent widgets, like combobox
or entry, installing their own bindings for these
keys, overriding the activation behavior that
is implemented in gtkwindow.
This solves issues with parent widgets, like textview
or scrolled window or combobox installing their own
bindings for these keys, overriding the focus behavior
that is implemented in gtkwindow.
Add a convenience api to skip children
that should not be included in the layout,
and call gtk_native_check_resize on all
native children outside of the vfunc.
We can't call gtk_widget_destroy on something
that wasn't added as a child to a container -
it ends up calling gtk_container_remove, which
asserts if it doesn't find the child.
Make gtk_widget_real_focus do the right
thing for focusable widgets with children.
A case where this is (now) relevant is
an entry with a context popover.
Differentiate between wrapping around and
stopping at the end of the focus chain.
Update the existing tests, and add two
new ones where the difference matters.
