It would be nicer if we could have the tests specify what environment
their expected output was created in, then we could test multiple
scenarios. For now, just fix the setting to avoid test failures.
When running on quartz, it is no longer expected for applications to
provide their own application menu. Instead, they should simply ensure
that they provide "app.about", "app.preferences" and "app.quit" actions
(which many apps are already doing).
A default menu will be shown that looks like the one presented by all
other Mac OS applications, containing menu items for the above actions,
as well as the typical "Hide app", "Hide Others and "Show All" items and
the "Services" submenu.
If an application does explicitly set an application menu (via
gtk_application_set_app_menu()) then it will be respected, as before.
https://bugzilla.gnome.org/show_bug.cgi?id=720552
Add support for extracting strings from GMenu markup in GtkBuilder
files.
This means that we have to support translatable <attribute/> tags.
Unfortunately, <attribute> is also used by GtkTreeViewColumn and
GtkLabel for other purposes, and those other purposes use a value=''
(XML) attribute, so we must accept (and ignore) that in order not to
have errors. Nothing will happen in those cases because they do not
also specify translatable='yes', so we ignore them.
https://bugzilla.gnome.org/show_bug.cgi?id=720552
Add a new private API to GtkApplication akin to
gtk_widget_insert_action_group().
We'll use this to insert a few extra actions at the app level with a
separate namespace for the special items in the Mac OS application menu.
https://bugzilla.gnome.org/show_bug.cgi?id=720552
Add a private hack to allow the insertion of the name of the application
into the label of menu items.
If it appears in the label of any menu item, "%s" will be replaced with
the name of the application.
We will use this for the "Hide myapp", "Quit myapp" and "About myapp"
labels typically found on Mac OS programs.
https://bugzilla.gnome.org/show_bug.cgi?id=720552
Allow the possibility for items to be marked with a special attribute and
expose this via GtkTrackerMenuItem. For internal use only.
We will use this to implement the special 'Hide', 'Hide Others' and 'Show All'
items and the 'Services' submenu in the Mac OS application menu.
https://bugzilla.gnome.org/show_bug.cgi?id=720552
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
