GtkApplicationWindow frees its internal action group on dispose for the
usual reasons: to avoid the possibility of reference cycles caused by
actions referring back to the window again.
Unfortunately, if it happens to be inside of a GtkActionMuxer at the
time that it is disposed, it will (eventually) be removed from the muxer
after it has been disposed. Removing an action group from a muxer
involves a call to g_action_group_list_actions() which will crash
because the internal action group to which we normally delegate the call
has been freed.
A future patch that reworks the quartz menu code will introduce a use of
GtkActionMuxer in a way that causes exactly this problem.
We can guard against the problem in a number of ways.
First, we can avoid the entire situation by ensuring that we are removed
from the muxer before we destroy the action group. To this end, we
delay destruction of the action group until after the chain-up to the
dispose of GtkWindow (which is where the window is removed from the
GtkApplication).
Secondly, we can add checks to each of our GActionGroup and GActionMap
implementation functions to check that the internal action group is
still alive before we attempt to delegate to it.
We have to be careful, though: because our _list_actions() call will
suddenly be returning an empty list, people watching the group from
outside will have expected to see "action-removed" calls for the
now-missing items. Make sure we send those. but only if someone is
watching.
https://bugzilla.gnome.org/show_bug.cgi?id=710351
A widget intended to offer contextual actions for a given view.
It allows packing children into the start or end as well as offering
a single centered child box.
https://bugzilla.gnome.org/show_bug.cgi?id=721665
Notifications can only be associated with application actions,
but clear is a window action. Introduce a "clear-all" action
that forwards to clear on all windows.
https://bugzilla.gnome.org/show_bug.cgi?id=721633
Add gtk_tree_path_new_from_indicesv which takes an array of
integers with a length. Use "Rename to" annotation to rename the
method as gtk_tree_path_new_from_indices. This is needed because
the original method takes variadic arguments which is not supported
by introspection.
https://bugzilla.gnome.org/show_bug.cgi?id=706119
GtkMenuItemAccessible was assuming that an accel label is
always the immediate child of a menu item. It also did not
deal with manually set accels. Fix both of these.
https://bugzilla.gnome.org/show_bug.cgi?id=721086
Improve the color swatch accessible to set a proper role
depending on whether the swatch is selectable or not, and
set the checked atk state when appropriate.
https://bugzilla.gnome.org/show_bug.cgi?id=721048
The initial state of GtkModelMenuItem is that of a normal menu
item, but the accessible we are using, GtkCheckMenuItemAccessible,
starts out with a role of 'check menu item'. Fix that up by
explicitly setting the initial accessible role.
GtkModelMenuItem does not emit the ::toggled signal when a radio
item is activated, so listen for property notification for that
property. We still keep the ::toggled signal handler, in order
to not break other uses of check and radio menu items.
https://bugzilla.gnome.org/show_bug.cgi?id=720983
GtkModelMenuItem emits no property notification, since none of its
properties are readable. But the toggled property is just a proxy
for GtkCheckMenuItem::active, so we should ensure that property
notification is emitted for the ::active property.
Ensure the hscrollbar & vscrollbar at gtk_scrolled_window_add() time,
this allows one to subclass GtkScrolledWindow with templates and add
children, as this will happen at instance initialization time before
the construct adjustment properties take effect.
And update the colorchooser a11y test to a) use GtkColorChooser
instead of the deprecated GtkColorSelection and b) match this
change. Pointed out in
https://bugzilla.gnome.org/show_bug.cgi?id=721045
