GNOME Bugzilla – Bug 675154
Provide an application menu
Last modified: 2015-09-01 14:25:50 UTC
See https://live.gnome.org/GnomeGoals/PortToGMenu Suggested app menu format: New Window --- Send/Receive > --- Download Messages for Offline Usage Forget Passwords Work Offline --- Plugins Preferences --- Help About Evolution Quit
I think the Evolution team needs to discuss this before any action is taken here, as I'm not yet convinced application menus are a good idea.
"New Window" is an extremely uncommon usecase for me. "New message" would make more sense. I have never ever used "Forget Passwords" in my life. "Download Messages for Offline Usage": I get a dialog asking me anyway if I choose "Work Offline". But how often is that needed? Going to the Plugins os Preferences configuration also sounds rather uncommon if you don't want to change your basic preferences every day. Maybe I get it wrong, so asking: What are App Menus for? Providing commonly used stuff, or just exposing some settings even if they are really rarely used?
(In reply to comment #2) > "New Window" is an extremely uncommon usecase for me. "New message" would make > more sense. > I have never ever used "Forget Passwords" in my life. > "Download Messages for Offline Usage": I get a dialog asking me anyway if I > choose "Work Offline". But how often is that needed? > Going to the Plugins os Preferences configuration also sounds rather uncommon > if you don't want to change your basic preferences every day. > > Maybe I get it wrong, so asking: What are App Menus for? Providing commonly > used stuff, or just exposing some settings even if they are really rarely used? I'm intentionally being conservative in my recommendation - basically just suggesting what to copy across. If some of these menu items don't make sense then by all means get rid of them. The main point of the app menu in this situation is to be a place for global application options. Things like New Window or Work Offline affect the whole application. It therefore makes sense to elevate them into an app-level location. The other thing I've made an effort to do in this recommendation is relocate those menu items that don't fit comfortably within the existing menubar structure (eg. what does 'Work Offline' have to do with 'File'?).
Hm, is Evolution planning to add an app menu in time for 3.10? As of 3.8, every other major GNOME app has one, and Evolution sticks out badly. I don't think app menus are optional. I'm not sure Allan's suggestion is best, though, since it seems like the options selected are kind of random. Missing global options, from each menu: File: New (but it wouldn't possibly fit), Backup, Restore, Import Edit: Message Filters View: almost everything (but it wouldn't possibly fit) Message: Compose New Message Folder: New, Subscriptions Search: Advanced Search, Edit Saved Searches Help: everything Evolution has so many global options that it'd be hard to fit them all into the app menu. My suggested bare minimum approach would be: New Window --- Send/Receive > All Accounts Account X Account Y Account Z --- Plugins Preferences --- Quick Reference Help About Evolution Quit Gather up just a few more options and we're pretty much at the limit of what an app menu can handle. But we could get an actually useful menu by using submenus like Empathy (which get scrollbars when the menu is too big): New Window --- New > --- Send/Receive > All Accounts <Account X> <Account Y> <Account Z> --- Search > Advanced Search Saved Searches --- Data > Import Backup Restore --- Empty Trash Forget Passwords --- Work Offline Download Messages --- Subscribed Folders Message Filters Plugins Preferences --- Help > Quick Reference Contents About Evolution Quit The items that stay in the traditional menubar should probably reviewed as well. E.g. under the Edit menu, Delete Message and Undelete Message probably belong on the Message menu, and Find in Message would make more sense under Search. If we put Search there, the Search menu could be removed if a toolbar button is added for Save Search. I cannot imagine anybody uses the "Find Now" option instead or pressing Enter, or the "Clear" option instead of using the broom icon. There's a lot of possibilities, but I really think we should implement at least a minimal menu for 3.10; UI freeze is in a month and a half. I can do this if needed (but I'm sure the developers would rather).
I'll be adding an app menu for GNOME at the same time I add a messaging menu for Unity/Xfce. But at the moment it's not a high priority.
I guess you've got plenty else to work on. But it is a priority for GNOME. :( If we could work out a design here, would you accept patches?
(In reply to comment #4) > My suggested bare minimum approach would be: Where are the recommendations for app menus (URL)? Should they list common global actions? Or all global actions?
The only official guidance I know of is [1]. The relevant bit is "If the application has a complex menubar, simply ensure that a small number of key items are moved to the app menu." Evolution definitely qualifies there. (My second recommendation above, with 16 top-level actions, might be bad as it's possibly just too much stuff for smaller resolutions: the biggest app menu I know of is Empathy's, which works well, but has only 11 top-level actions.) There's also some WIP guidelines at [2] and some clarification at [3]. [1] https://wiki.gnome.org/GnomeGoals/PortToGMenu [2] https://wiki.gnome.org/Design/HIG/ApplicationMenus [3] https://mail.gnome.org/archives/desktop-devel-list/2013-July/msg00015.html
Alright. https://bugzilla.gnome.org/show_bug.cgi?id=695377#c2 says that "Items in that menu shouldn't be frequently used." so following https://mail.gnome.org/archives/desktop-devel-list/2013-July/msg00013.html we probably only want to hide stuff there that nobody really needs anyway because not many people will discover it there anyway. Which means that I wouldn't exclusively move "Quit" there, for example.
I'm not going to *move* anything there. If I add an app menu at all it will supplement, not replace, items in Evolution's main menu. I'm not going to butcher our menus just for one specific desktop environment.
Well "Quit" doesn't seem like a good example; have you ever used it? I click the X in the top right. (And besides, "Quit" is right above "Close Window.") But I guess Allan will have to provide further guidance on how he wants this to work, since Emmanuel was pretty clear that the app menu is not supposed to share items with the traditional menu. (I kind of agree; what's the point of having a redundant menu?) Remember that outside of GNOME, it will show up as an "Evolution" menu immediately to the left of the "Files" menu, so everything will still be in the menubar. (Though you could manually prevent that.)
(In reply to comment #11) > But I guess Allan will have to provide further guidance on how he wants this to > work, since Emmanuel was pretty clear that the app menu is not supposed to > share items with the traditional menu. (I kind of agree; what's the point of > having a redundant menu?) What's the point in having to search in two menus for the item that you want instead of one, while one menu might be far off from the application window that you use? As it won't completely replace any existing toplevel menu entry, it will just create yet another menu to search through.
What's the point of having the same menu option in two different menus? But I don't completely disagree with you; I do however think that Evolution should be consistent with what the other apps that retain traditional menus are doing. I brought this up at [1] so let's see where that goes. [1] https://mail.gnome.org/archives/desktop-devel-list/2013-July/msg00035.html
I have no objection to adding an application menu, for those who really want a menu to appear somewhere *other* than in the application window where it naturally belongs. But like Matthew in comment 10, I really don't want to remove items from the existing menus. The in-application workflow should *not* involve moving from the application's window. Especially when that window may be a *long* way from the location of the shell's menu bar, on a large screen.
(In reply to comment #13) > What's the point of having the same menu option in two different menus? There isn't much point, because we don't really need an app menu. But GNOME people are insisting that we have one. So this is a compromise. I'm more concerned with Evolution working consistently across various desktop environments than with core apps from one particular desktop environment, especially since I'm not planning to move to GMenuModel any time soon.
Two years later, I think we've learned that minimal app menus are better than expansive ones. Something like this (copied from my post above) would work well: New Window --- Send/Receive > All Accounts Account X Account Y Account Z --- Plugins Preferences --- Quick Reference Help About Quit It would work well without the Send/Receive section, too. The designers intend for these items to be removed from the menu bar when they are moved to the app menu, but the HIG do not specify this [1], so apps are choosing inconsistently whether to do so or not. I think it's fine to leave the menu items in the menu bar, unless contrary guidance is added to the HIG in the future. [1] https://developer.gnome.org/hig/3.17/application-menus.html.en
Created attachment 310398 [details] [review] proposed evo patch for evolution; Let's have it for GNOME only, and have there only: New Window -------------- Preferences -------------- Quick Reference Help About Quit where the Quick Reference is hidden, in case the expected .pdf file is not found in the system. This patch moves strings around the sources, but doesn't change them. Due to mnemonic clash there is one new localized string "Quick _Reference".
I've got an approval, thus I committed the patch into the sources. Created commit ee35850 in evo master (3.17.92+)