Re: Application menus

[Emmanuele Bassi <ebassi gmail com>]

hi;

On 4 July 2013 22:18, Michael Catanzaro <mike catanzaro gmail com> wrote:
> I haven't seen an app menu (gmenu) discussion in quite some time,

I had hoped people finally moved on. :-)

> which is a bit surprising as more apps add them. 3.10 will be the fourth
> release featuring app menus, and by now most GNOME applications have
> one.

finally.

> But the only information on the GNOME wiki seems to have been
> written for GNOME 3.4, and there seem to be some issues and
> inconsistencies with the implementation throughout the project.
>
> 1) For applications that retain a traditional menu bar, there's
> inconsistency in whether options added to the app menu are also removed
> from the traditional menu. E.g. Gedit and Totem (3.6/3.8) removed Help,
> About, and Preferences from their traditional menu, but Terminal, Eye of
> GNOME, and Aisleriot have left them where they were (so they're now in
> two places). We need to pick one method and use it consistently.

yes. file bugs against applications that do not move them consistently.

when in doubt, ask the maintainers and the designers to talk and clear
out any doubts.

> Removing the items from the traditional menus has led to lots of
> confused users, but not removing them I guess leads to duplicate menu
> entries outside of GNOME Shell, so I guess removing is better? We need
> policy here.

there is a policy. it's also being polished, so if you're expecting a
specific set of iron-clad rules you will probably be unsatisfied.

> 2) Some apps still don't have an app menu. Hi Evolution, hi Brasero!
> Brasero is almost unmaintained but the Evolution team is incredibly
> active, so they must have a reason for not wanting one (probably
> concerned about mixing app menus with traditional menubars?). But to
> have a consistent desktop, app menus surely have to be a requirement for
> GNOME programs.

again, file bugs.

> 3) There's significant inconsistency in menu elements. Half place About
> above Help, half below. Half say "About <program name>" and half leave
> out the program name.  Some new ones don't even have Quit -- I'm looking
> at GNOME Terminal and Evince here.

file bugs. the HIG on the wiki says:

> Items that should be placed in the application menu if they are available
> include New Window, Full Screen, Preferences, Help and About.
-- https://wiki.gnome.org/Design/HIG/ApplicationMenus

if the HIG needs to be clarified, hop in #gnome-design on
irc.gnome.org, and ask where to file bugs.

> 4) I'm confused about what qualifies as "window-specific behavior" that
> doesn't belong in an app menu -- it seems like such an easy question, at
> least until you're actually picking what options go in the app menu. I'm
> writing an app menu for GNOME Chess, but am not sure what can and cannot
> go there. Every GNOME game puts "New Game" in the app menu, and I don't
> want Chess to be inconsistent with them by leaving it out, but if I put
> "New Game" there, I also will want to put Open and Save there as well.

'Save' is clearly a per-window option: you're saving *that* game.
'Open' is debatable, though I'd probably recommend using it in the
window as well. you could simply have 'New Game' in the app menu and
open a dialog that lets you choose between a new game, a recently
opened/saved game, or to explicitly open a saved game.

in any case, you should bring this discussion to the design team, as
it will improve the HIG recommendations.

> 5) An application menu is required for proper integration into GNOME
> Shell -- what kind of reject app has a menu with only "Quit?" -- but
> almost no third-party apps (Firefox, Shotwell, LibreOffice) are using
> them, and it seems unlikely they will anytime soon (or ever, for apps
> that only care about Unity... I feel like Shotwell is one of these).

we knew that when the feature was designed and implemented: it takes a
while to get a new UI feature out in the while, especially if you're
not downstream, and thus can patch all non-complying applications.

application menus are not a GTK-only feature: other applications can
expose their menu structure on the session bus, and the Shell will
pick it up — assuming they namespace the actions.

the actions API is also being moved under freedesktop.org, alongside
with other application-related features; there's also a wiki page
detailing the DBus API we use, and how to access the various objects
representing actions on the session bus in order to construct the
menus:

https://wiki.gnome.org/GApplication/DBusAPI

> And anything Qt is completely out of luck. Given current momentum in favor
> of Qt and Unity, I think we have to accept that most apps used in GNOME
> Shell are not going to be written with it in mind, and come up with
> something nicer than just showing "Quit" there. But I have no idea what.

Qt can support application menus: the system is completely toolkit
agnostic - in fact, it's the same system used by Unity to support
putting the whole menu bar inside the top panel. it's one of the
reasons why the whole system was redesigned and reimplemented the way
it is now, with GMenuModel.

as for "most apps used in GNOME Shell are not going to be written with
it in mind": I fail to connect that with Unity being rewritten in Qt
(this cycle).

ciao,
 Emmanuele.

--
W: http://www.emmanuelebassi.name
B: http://blogs.gnome.org/ebassi/