Application menus

I haven't seen an app menu (gmenu) discussion in quite some time, 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. 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.
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.

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.

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.  Evince's in particular is a complete
mess: it has ONLY "Help," -- About in its gear menu instead, as is
"Close." I think Evince doesn't want to have a way of closing all
windows at once, and maybe that's what's up with Terminal as well.
Perhaps apps with multiple windows should define Quit to close only
related windows, instead of all of them. Can we agree that
Help/About/Quit should be required in the app menu? Quit is the one
thing that used to be guaranteed to be there, even for third-party apps,
and I don't think users should ever have any question as to where it is.

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.
(This would work because Chess currently allows only one window at
most.) But if those game-specific options go there, then I'd want to
throw in "Resign," "Undo Move," and "Claim Draw," as well. I'd do this
by reasoning that these options affect the state of the only game in a
single-instance app. But the GNOME goal specifically lists "Open" and
"Save" as window-specific things that shouldn't go in the app menu. So
how can "New Game" belong there -- surely that's a parallel option to
Save and Load, and either they should all be there or none of them
should be? Do single-instance apps need different guidelines from
multi-instance apps? (I hope not; that'd get confusing, and then
wouldn't a "unique" app be able to put anything at all into the app
menu?) What about Pause, Undo Move, and Fullscreen -- some other games
currently put these in the app menu, but, inconsistently, others don't.

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

Thanks for reading,

Michael Catanzaro

Attachment: signature.asc
Description: This is a digitally signed message part

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