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:

https://gitorious.org/gnome-design/gnome-design/blobs/raw/2ecc0f45b0c4893bd36a6df69bae3c8fedd05251/mockups/documents/documents-app-menu.png https://github.com/gnome-design-team/gnome-mockups/raw/master/boxes/boxes-menu.png

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.

ThreePointThree/Features/ApplicationMenu (last edited 2012-02-07 21:56:03 by JeremyBicha)