Re: Application menus


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


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.

if the HIG needs to be clarified, hop in #gnome-design on, 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, 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

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).



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]