Provide a mechanism for hiding the "Quit", "About" and "Preferences"
menu items from the normal places in a traditional menubar layout (in
the File and Edit menus) when the menu is being rendered in the Mac OS
menubar.
These items can already be found in the application menu.
With this feature, applications can now define a single menu to use in
all 'traditional' scenarios.
Use this new attribute in Bloatpad.
https://bugzilla.gnome.org/show_bug.cgi?id=741610
Previously GtkMenuTracker tried to access "gtk_menu_tracker_item_get_is_visible",
but the correct getter is "_gtk_menu_tracker_item_is_visible". This commit
corrects this reference
https://bugzilla.gnome.org/show_bug.cgi?id=731430
The signal handler for the visibility of menu items changing had the
wrong signature, resulting in the GParamSpec from the notify signal
being treated as a boolean (which was always true). This resulted in
items being added over and over and never being removed.
Fix that...
Add the possibility of a GtkMenuTracker that performs no section
merging. Instead, it will report an item in the form of a separator for
subsections. It is then possible to get a separate tracker for the
subsection contents by using gtk_menu_tracker_new_for_item_link().
We have some API in GtkMenuTracker and GtkMenuTrackerItem that is
specifically designed to deal with submenus.
Generalise these APIs to take a 'link_name' parameter that we always
give as G_MENU_SUBMENU for now. In the future, this will allow creating
trackers for other types of links, such as sections.
Make this a property just like all of the other things and make the APIs
for accessing it non-private (but add a note that they are not intended
to be used).
Modify the tracker so that it manages the visibility of
GtkMenuTrackerItem by issuing insert and remove callbacks to the
user of the tracker.
This works by treating the GtkMenuTrackerItem as a virtual section which
contains 1 item when the item is visible and 0 items when it is hidden.
For efficiency reasons, we only employ this trick in the case that the
item has a hidden-when='' attribute set on it.
https://bugzilla.gnome.org/show_bug.cgi?id=688421
Remove a hash lookup from the separator sync logic (which is run every
time we change a menu). Instead, we do the lookup when creating the
section and cache the result.
This refactor will also help us in a future commit to add support for
hiding menu items based on missing actions.
https://bugzilla.gnome.org/show_bug.cgi?id=688421
Ignacio Casal Quinteiro reported a problem whereby an empty section at
the start of a menu has a separator placed after it. This was caused by
the implementation of the logic that separators should be inserted at
the top of all non-empty sections that are not the first section. This
logic is obviously incorrect in the case that the first section is empty
(in which case we would not expect to see a separator at the top of the
second section).
Change the logic so that we only insert separators when we see a
non-zero number of actual items in the menu before us.
https://bugzilla.gnome.org/show_bug.cgi?id=721119
gtk_menu_tracker_add_items() fetched the action-namespace from the menu
item, but didn't pass it into gtk_menu_tracker_section_new() when its
internal namespace was still NULL.
https://bugzilla.gnome.org/show_bug.cgi?id=712164
Add a new class, GtkMenuTrackerItem that represents a menu item, to be
used with GtkMenuTracker.
GtkMenuTracker's insert callback now works in terms of this new type
(instead of passing reference to the model and an index to the item).
GtkMenuShell now handles all of the binding tasks internally, mostly
through the use of property bindings. Having bindings for the label and
visibility attributes, in partiular, will help with supporting upcoming
extensions to GMenuModel.
GtkModelMenu has been reduced to a helper class that has nothing to do
with GMenuModel. It represents something closer to an "ideal" API for
GtkMenuItem if we didn't have compatibility concerns (eg: not emitting
"activate" when setting toggle state, no separate subclasses per menu
item type, supporting icons, etc.) Improvements to GtkMenuItem could
eventually shrink the size of this class or remove the need for it
entirely.
Some GtkActionHelper functionality has been duplicated in
GtkMenuTracker, which is suboptimal. The duplication exists so that
other codebases (such as Unity and gnome-shell) can reuse the
GtkMenuTracker code, whereas GtkActionHelper is very much tied to
GtkWidget. Supporting binding arbitrary GtkWidgets to actions vs.
supporting the full range of GMenuModel features for menu items turns
out to be two overlapping but not entirely similar problems. Some of
the duplication (such as roles) can be removed from GtkActionHelper once
Gtk's internal Mac OS menubar support is ported to GtkMenuTracker.
The intent to reuse the code outside of Gtk is also the reason for the
unusual treatment of the enum type introduced in this comment.
This adds no new "public" API to the Gtk library, other than types that
we cannot make private due to GType limitations.
GtkMenuTracker folds a nested structure of sections in a GMenuModel into
a single linear menu, which it expresses to its user by means of 'insert
item at position' and 'remove item at position' callbacks.
The logic for where to insert separators and how to handle action
namespaces is contained within the tracker, removing the need to have
this logic duplicated in the 3 or 4 places that consume GMenuModel.
In comparison with the previous code, the tracker no longer completely
destroys and rebuilds menus every time a single change occurs. As a
result, the new gtkmenu testcase now runs in approximately 3 seconds
instead of ~60 before.
https://bugzilla.gnome.org/show_bug.cgi?id=696468
