Application menu / Actions
Status: Complete
Description
This got tied up in the back-and-forth over GApplication and never really got finished.
The mail thread starting at http://mail.gnome.org/archives/desktop-devel-list/2011-February/msg00086.html has some details from a session about this at the 2010 Boston Summit.
The current thinking on this is roughly as follows:
Static dash menu extensions or jumplists are not that interesting, we want to focus on the application menu. (For jumplists, see this page).
- The app menu needs to be dynamic (i.e. apps need to have a way to update the menu contents as their state changes), to accomodate sensitivity changes of actions, and e.g. window state (fullscreen / not fullscreen)
- While submenus in the shell are nicer than GTK+ submenus, it is best to avoid submenus as far as possible
- The menu needs to support controls such as
- toggles
- radio groups with title
- separators
We need a global design for edit menu replacements, this is very similar in all apps (see GnomeOS/Design/Whiteboards/Selections)
- Loss of discoverability of keyboard shortcuts is a concern; this should be addressed in GTK+ by providing a shortcut overview screen for each window (similar to what google apps show when you press '?')
- 'Portability' could be a concern that keeps apps from dropping their menus
Current mockups involving appmenu examples:
Apps that would make good initial targets for this are:
- Epiphany
- Baobab
- Cheese
- gnome-documents
- gnome-contacts
- Boxes
- Totem (?)
- Empathy (?)
Apps that will probably not be able to drop their menus anytime soon include
- inkscape
- gimp
- libreoffice
This is not a problem - it is fine for such applications to keep their traditional menus
Owner
Colin Walters, Ryan Lortie
Involved Parties
GNOME Shell team, GIO developers, GTK+ team
Current Status
Originally planned for 3.2, now implemented in 3.4.
In 3.2, GApplication allows to advertise and activate actions over D-Bus and the gnome-shell app menu shows the title and icon of the currently active
- window, and its menu just contains a generic 'Quit' action.
At the BostonMontreal Summit, Ryan Lortie unveiled a set of APIs that he has been working on for Canonical, for replacing libdbusmenu in Ubuntu. The main parts of the new API are a 'menu model', GMenuModel, which encodes enough information about a menu to render it. The menu model gets exported over DBus, together with the GActions to which it refers. The API is more general than what is needed for app menu support, since it also aims at supporting 'global menu' platforms such as OS X and unity.
GMenuModel code has been merged in GLib master and has appeared in GLib 2.31.4. The API is currently being discussed on gtk-devel-list.
For the APIs, see the GIO documentation.
GTK+ support of GMenu, including initial support for global menus on OS X, has been merged in GTK+ master and has appeared in GTK+ 3.3.6.
For the APIs, see the GTK+ documentation.
Various other bits of supporting code have been included in the latested 3.3.x releases of mutter and gnome-settings-daemon.
The gnome-shell support for app menus is included in the 3.3.4 release.
On the application side, the following have some initial app menu support:
- Boxes
- Contacts
- Documents
- Iagno (3.3.90)
- Mines (3.3.90)
- Tetravex
- Web
How to Help
Try out app menus in GNOME 3.3.4 or newer. Try to use the APIs in your application, and let us know what is working and what is missing.