By default, Mac OS scans menus as they are opened, updating the
sensitivity of each item in the menu.
The current code in gtkapplication-menu-quartz disables this behaviour,
preferring to manually control the sensitivity of each item in the menu
(when told by the tracker that it has changed internally).
Change the way that this works to more closely follow the usual Mac OS
regime.
This will allow us to construct a typical "application menu" on Mac OS
containing the items that are typically found there ("Hide", "Hide
Others", "Show All", "Services") and have the OS automatically update
their sensitivity.
https://bugzilla.gnome.org/show_bug.cgi?id=720552
Add a custom title had the side-effect of showing the widget.
That is not right, adding children and managing their visibility
should be independent. The headerbar size allocation code also
made the assumption that a custom title is always visible.
With these changes, GtkHeaderBar should be usable in situations
where the centering functionality is not required, and it is
important to freely pack content at both ends, such as in nautilus.
https://bugzilla.gnome.org/show_bug.cgi?id=722340
Use a GtkHeaderBar for the credits and about buttons.
It makes less sense here than in other places to go back to
the buttons on the bottom, considering we only have a close
button, so we always use a header bar.
https://bugzilla.gnome.org/show_bug.cgi?id=720059
This commit introduces a private convenience API that derived
dialogs can call in their instance init. This is necessary to
make the setting work as intended in the face of 3rd party
dialogs derived e.g. from GtkFileChooserDialog, which are
created with g_object_new.
This setting will let us keep traditional appearance
of dialogs on platforms where this is expected.
The new setting is called gtk-dialogs-use-header, backed
by the Gtk/DialogsUseHeader xsetting.
This change makes it possible for GtkDialog to pack
its action widgets into a header bar, instead of the
traditional action area. This change is controlled
by the use-header-bar construct-only property.
https://bugzilla.gnome.org/show_bug.cgi?id=720059
Stop trying to deal with "theoretical possibilities".
We can't possibly continue to be a faithful GActionGroup implementation
across dispose because dispose has a side effect of removing everyone's
signal handlers.
The code that we ran after the dispose chainup to do all of the fancy
signal emulation was therefore dead. The test that aimed to verify this
was buggy itself due to an uninitialised variable, so really, it never
worked at all.
We keep the re-ordering of the chainup from the original commit to avoid having
trouble with GtkActionMuxer and keep the checks in place that will prevent an
outright segfault in the case that someone else tries to use the interface
post-dispose.
https://bugzilla.gnome.org/show_bug.cgi?id=722189
