In the n == 2 case, we want to avoid the buttons being
drawn all the way out to the ends of the box, but in the
n >= 3 case, that is exactly what we want for the first
and last button.
When the icon theme changes, we want to both initiate
a css SOURCE change (since css values may depend on the
icon theme), as well as calling gtk_system_setting_changed,
since widgets need to drop cached images, e.g. in GtkIconHelper.
Replace calls to gtk_style_context_reset_widgets by
gtk_system_setting_changed, with the appropriate setting,
and add style invalidation where required.
This gives us a hook to walk the widget tree whenever a global
setting changes and do per-widget invalidations. This will
replace gtk_style_context_reset_widgets().
Add the following actions:
* window.close
* window.toggle-maximize
* window.minimize
Ensure they are disabled when not appropriate, such as for modal windows.
Use them in GtkHeaderBar.
The application menu isn't particular relevant anymore, and the support for
showing fallback appmenu as a headerbar icon is one of the things tying
GtkWindow to GtkHeaderBar.
Remove support for "menu" window decoration element completely, update
GtkHeaderBar docs.
When freeing the display GtkIconTheme and that was the last owner we
ran into a deadlock, because we unref the "next-to-last" ref inside a
gtk_icon_theme_ref_aquire/release() pair, which makes the final unref
to happen in the release(), while the ref lock still was held.
The unref triggers dispose which tries to NULL out the ref, but that then
deadlocks on the mutex being held by the caller already.
We fix this by moving the release unref outside the lock. This is safe
because refcounts are atomic, and we *do* own the ref.
- HC got caught up on a condition made for color (suggested) buttons.
the rule just made the slider a tag lighter on dark probably due to the
overlaid AA making it stronger. Got rid of it for now, if someone cares
enough we can reintroduce an exception (that doesn't break HC).
When toggling caret visibility (with F7) we would hit an assertion if the
cursor is currently blinking. This adjusts things to ensure that we should
be showing the carent when scheduling our blink timeouts.
Fixes#2647
Emit accessible change signals after setting the
new selection limits. This was broken in
commit f6bedd0d5e, and showed up as broken
accessibility tests.
This was only living in gtkcontainer.c for historic
reasons. Move it closer to where it belongs, and
rename it from 'idle' to 'layout', since it is
really about the layout phase of the frame clock,
nowadays.
These popovers handle clicks outside the widget, and expect input
to be routed through it when it is shown. This pretty much matches
the characteristics of GTK grabs, and setting one up will ensure
the cancellation of event controllers that were active at the time
of showing the popover.
Closes: https://gitlab.gnome.org/GNOME/gtk/-/issues/2446
