GNOME Bugzilla – Bug 609114
Application menu
Last modified: 2012-06-07 03:50:04 UTC
Here's a quite rough mockup: http://www.gnome.org/~mccann/screenshots/clips/20100205010418/shell-mockup-appicon-menu.png Things to note: * This example has three sections Open Windows, Extension Points / Jump list, Shell builtin functionality. * The jumplist type functionality should probably vary per app * We may want to use some of this for the App menu that appears in the top bar. * I think the "selected" item should be styled like we do for the app well - an outline. We may want to try using inverse too. * Things that are dynamic objects (documents, pages, etc) should have icons. The rest should not (eg. actions). * You may notice that I bungled some of the intraline and border spacing - this is not on purpose. :) * This turned out to be very similar to the snow leopard menus. Only noticed this afterwards but I am not too troubled by it. However, at some point we may want to restyle it slightly. Things not seen in the mockup. * I'd like to drop the zooming into the windows when bringing up and navigating through the menu. * I happy to try dimming out the windows that don't belong to this app - as suggested on the mail list. * We'll probably want to use similar but not identical styling for the App menu in the top panel. In particular, it probably won't have the arrow and the items in the list will be different. I'll try to do another drawing and bug for that. Anything that needs clarification before we start?
(In reply to comment #0) > [..] > * I'd like to drop the zooming into the windows when bringing up and > navigating through the menu. > * I happy to try dimming out the windows that don't belong to this app - as > suggested on the mail list. > [...] > Anything that needs clarification before we start? What should be done when the window in question is on another workspace and the workspace view is set to linear view? Dimming all windows would be rather confusing.
(In reply to comment #1) > What should be done when the window in question is on another workspace and the > workspace view is set to linear view? > > Dimming all windows would be rather confusing. Still much better than the current behavior though ... On the technical side: Should we follow the current ShellGenericContainer/ShellMenu implementation or would it make sense now to import MxPopup (as in bug 601864 for Nbtk)?
(In reply to comment #2) > (In reply to comment #1) > > What should be done when the window in question is on another workspace and the > > workspace view is set to linear view? > > > > Dimming all windows would be rather confusing. > > Still much better than the current behavior though ... I don't disagree here but when designing something new, we should think on how to integrate it with the rest of the shell (knowing that the current situation is "broken").
(In reply to comment #1) > (In reply to comment #0) > > [..] > > * I'd like to drop the zooming into the windows when bringing up and > > navigating through the menu. > > * I happy to try dimming out the windows that don't belong to this app - as > > suggested on the mail list. > > [...] > > Anything that needs clarification before we start? > > What should be done when the window in question is on another workspace and the > workspace view is set to linear view? > > Dimming all windows would be rather confusing. Interesting point. One possible solution would be to dim the visible windows and somehow indicate that the windows in the list aren't visible - maybe light up the workspace indicators (squarish things under the workspace) where they are visible?
(In reply to comment #4) > (In reply to comment #1) > > (In reply to comment #0) > > > [..] > > > * I'd like to drop the zooming into the windows when bringing up and > > > navigating through the menu. > > > * I happy to try dimming out the windows that don't belong to this app - as > > > suggested on the mail list. > > > [...] > > > Anything that needs clarification before we start? > > > > What should be done when the window in question is on another workspace and the > > workspace view is set to linear view? > > > > Dimming all windows would be rather confusing. > > Interesting point. One possible solution would be to dim the visible windows > and somehow indicate that the windows in the list aren't visible - maybe light > up the workspace indicators (squarish things under the workspace) where they > are visible? Yeah another solution would be to temporary switch the workspace, dunno if this would be "to much".
I'm re-purposing this old bug as about improving the application menu: http://live.gnome.org/GnomeShell/Design/Whiteboards/AppMenu I'm now looking at making this thing work again; we got fairly far along with a specification for using G(tk)Application but that got pulled. We still have some (but not a lot) of time left in the Gtk/GLib cycles to add API this time. So - here is a brain dump of thoughts again. Phase 0: A way to make the implementation of Quit (what we have now) less bad. This is probably an explicit callback on GtkApplication via DBus. For non-GTK apps, potentially some X message they can hook into? Needs some research into prior bits (XSMP). Would ultimately likely only be used by major ISVs like Firefox/Chromium. Phase 1: Menu API This one has a lot of different tradeoffs, but let me describe what I'm thinking now. Basically, we embed actions in the .desktop file, similar to "Nautilus Actions": http://www.nautilus-actions.org/?q=node/377 Advantages: * Static: We know the set of actions without the application running, or even having had to run it once; this would enable say a note application to have a "New Note" action that the user could right click on without caring immediately whether it was running. * Simplicity: It's relatively easy for application authors to take advantage of this as it requires little code change. * GNOME 3 specific: If we avoid going through e.g. GTK+ for this, then we don't have to worry about the crossplatform constraints. For example, obvious questions with doing things like GTK+ were how does it map (if at all) to Windows 7 jump lists, etc. Disadvantages: * Static: * Not a full menu: More complex menu-like behavior is hard; things like checkboxes/toggles/radios etc. probably wouldn't be in a first cut, and I'm not sure it's sane to do any of that. Phase 2: Recent API The .desktop approach doesn't cover at all an important case which is a "Dynamic Recent" set. Think say Tomboy wanting to export a list of 5 recently used notes, or an IDE a list of 5 recently open projects, or a web browser exporting 5 recently visited web pages. (5 is totally arbitrary here) My intuition for this is that we add some sort of non-file extension to GtkRecentManager. Or, we could just ask that applications use a custom URI type. Say for example for the 3 cases above: app://tomboy/note/{uuid-goes-here} app://anjuta/project/gnome-shell app://epiphany/bookmarks/http%2B%3F%3Fnytimes.com (I'm not sure iff anything in the stack would barf on these now or just ignore them)
(In reply to comment #6) > Phase 1: Menu API > > This one has a lot of different tradeoffs, but let me describe what I'm > thinking now. Basically, we embed actions in the .desktop file, similar to > "Nautilus Actions": http://www.nautilus-actions.org/?q=node/377 I guess what you imply is these static actions will be mixed with dynamic actions exported by GtkApplication? Or do you want to list in the desktop file all possible actions? I'm thinking about your mockups here, where e.g. Firefox history or preferences wouldn't really be useful to see in a jump-list when Firefox is not running - so there's little point in having them static. > Phase 2: Recent API > > The .desktop approach doesn't cover at all an important case which is a > "Dynamic Recent" set. Think say Tomboy wanting to export a list of 5 recently > used notes, or an IDE a list of 5 recently open projects, or a web browser > exporting 5 recently visited web pages. (5 is totally arbitrary here) > > My intuition for this is that we add some sort of non-file extension to > GtkRecentManager. Or, we could just ask that applications use a custom URI > type. Say for example for the 3 cases above: > > app://tomboy/note/{uuid-goes-here} > app://anjuta/project/gnome-shell > app://epiphany/bookmarks/http%2B%3F%3Fnytimes.com > > (I'm not sure iff anything in the stack would barf on these now or just ignore > them) This could also be based on Zeitgeist, since it already has extensions to support most common apps. OTC Zeitgeist could build on this GtkRecentManager improvement, which IMHO would be a good idea. But in the short term using Zeitgeist as it works now would be easier for the Shell.
(In reply to comment #7) > I guess what you imply is these static actions will be mixed with dynamic > actions exported by GtkApplication? Or do you want to list in the desktop file > all possible actions? Good question; I was thinking the latter, actually. Things definitely become complex if we want to support hooking in some things from GtkApplication. Preferences is an interesting case here in that a lot of apps will want to support it, and having to jump through the hoop of adding: [X-GNOME3-Action Preferences] Name=Preferences ExecArgs=--remote=preferences Then supporting a --remote=preferenes commandline argument in your app, etc. Or alternatively via DBus: ExecDBus=org.example.MyApp org.example.MyApp.Preferences Though one detail that comes to mind now is that people are going to screw up timestamp handling =( I'm going to have to think about that... > I'm thinking about your mockups here, where e.g. Firefox > history or preferences wouldn't really be useful to see in a jump-list when > Firefox is not running - so there's little point in having them static. Well...think about a game which exported say "Resume Game", "New Game". But yes, I'm not going to go to great lengths to argue for this. One tricky part about any dynamic menu though is what do we do in the time span from launching the app to getting the menu data? How do we even know if a given app *has* a menu? Etc. > This could also be based on Zeitgeist, since it already has extensions to > support most common apps. OTC Zeitgeist could build on this GtkRecentManager > improvement, which IMHO would be a good idea. But in the short term using > Zeitgeist as it works now would be easier for the Shell. Hmm. Maybe. That takes it a lot more out of application control.
(In reply to comment #8) > Preferences is an interesting case here in that a lot of apps will want to > support it, and having to jump through the hoop of adding: > > [X-GNOME3-Action Preferences] > Name=Preferences > ExecArgs=--remote=preferences > > Then supporting a --remote=preferenes commandline argument in your app, etc. > Or alternatively via DBus: > > ExecDBus=org.example.MyApp org.example.MyApp.Preferences Doesn't this need to go through GtkApplication anyway? That is, to pass the commandline args to the running instance. I'm not saying having a menu when app is not running is bad, it's just that I wonder how you see this being implemented, and whether that won't create limitations (is there a use case for non-static menus?). > Well...think about a game which exported say "Resume Game", "New Game". Agreed, could be useful. > But > yes, I'm not going to go to great lengths to argue for this. One tricky part > about any dynamic menu though is what do we do in the time span from launching > the app to getting the menu data? How do we even know if a given app *has* a > menu? Etc. I don't see this as an issue: you can show static actions, if any. Menus aren't available/full until the app is fully started, but people are used to this, windows need time to be usable too. > > This could also be based on Zeitgeist, since it already has extensions to > > support most common apps. OTC Zeitgeist could build on this GtkRecentManager > > improvement, which IMHO would be a good idea. But in the short term using > > Zeitgeist as it works now would be easier for the Shell. > > Hmm. Maybe. That takes it a lot more out of application control. Not necessarily, since Zeitgeist plugins in each application can create the list of recent "tings" as they feel suited. I think that's a just an implementation difference; result doesn't change.
(In reply to comment #9) > (In reply to comment #8) > > Preferences is an interesting case here in that a lot of apps will want to > > support it, and having to jump through the hoop of adding: > > > > [X-GNOME3-Action Preferences] > > Name=Preferences > > ExecArgs=--remote=preferences > > > > Then supporting a --remote=preferenes commandline argument in your app, etc. > > Or alternatively via DBus: > > > > ExecDBus=org.example.MyApp org.example.MyApp.Preferences > Doesn't this need to go through GtkApplication anyway? That is, to pass the > commandline args to the running instance. Actually, the whole point of having GtkApplication instead of libunique is to get exportable GtkActions. Requiring a command line would be backwards. > > But > > yes, I'm not going to go to great lengths to argue for this. One tricky part > > about any dynamic menu though is what do we do in the time span from launching > > the app to getting the menu data? How do we even know if a given app *has* a > > menu? Etc. > I don't see this as an issue: you can show static actions, if any. Menus aren't > available/full until the app is fully started, but people are used to this, > windows need time to be usable too. Can't we have a static menu for applications which are not started (or don't export org/gtk/Actions), and a dynamic menu for applications which use GtkApplication? (Of course, this relies on startup notification happening after registration on the bus, but this should be normally the case) I was about to hack something based on GtkApplication when I stumbled on this bug, and I'm feeling perplexed by these decisions.
For the 3.0 release, is there enough benefit (I mean without jump lists etc) of having the application menu in the top panel? I agree it is still valuable in the dash. At the moment I think it has the following disadvantages 1) It offers only one choice (quit), which is just a duplicate of [x] 2) It looks out of place (colors on the right of the panel, monochrome on the left - except for the big oddly clipped/faded application icon 3) Visually duplicates the application name (which is already in the title bar)
Let me add; while the panel application menu does do a startup notification animation, I think this feedback could be accommodated more consistently by animating the dash icon. While the application is launching the dash icon could spin, and perhaps show, semi hidden, on the current workspace at the same vertical height it will lie in the dash. If that makes sense.
The application name is not supposed to be in the title bar.
(In reply to comment #13) > The application name is not supposed to be in the title bar. Bad Firefox/Chrome/EoG/Totem! (as of GNOME3 live CD 0.0.3) What about variations thereof - Move Player vs Totem, Eye of Gnome vs Image Viewer. It all seems very haphazard.
Sorry bout the dupes - I guess Chromium / bgo hates me.
http://library.gnome.org/devel/hig-book/2.32/windows-properties.html.en#window-props-titles (the text, ignore the example) Totem doesn't show the app name when playing.
Actually this is probably a bit more relevant http://library.gnome.org/devel/hig-book/2.32/windows-primary.html.en#primary-window-titles For HIG 3 we'll want to clarify this and likely change the recommendation for non-document based windows.
That works for GNOME, but I don't think we can expect Mozilla, OpenOffice or Google Chrome will stop using their brands in window titles. So maybe we can detect when window titles contain the name of the app, and remove it if possible. For example, Firefox says "Webpage-Mozilla Firefox", and we could easily detect the "-appname$" pattern to strip it out (same for OpenOffice). Of course, if the title is just the app name, we keep it. Does that sound reasonable?
Looks like Unity has picked the .desktop file approach: http://www.omgubuntu.co.uk/2011/04/how-to-unity-quicklists-for-libreoffice-gmail-and-chromium/
(In reply to comment #21) > Looks like Unity has picked the .desktop file approach: > > http://www.omgubuntu.co.uk/2011/04/how-to-unity-quicklists-for-libreoffice-gmail-and-chromium/ Maybe we can / should talk to them to agree on a common syntax / spec to make it easier for app authors.
Yes, I wanted to add jumplists to Firefox in Unity (initially as an extension), and it would be great if it worked on both desktops. The Unity implementation is currently pretty broken for the Firefox use-case though - you can either have static entries listed in the desktop file, or dynamic entries via the libunity API. The latter requires the application to actually be running, and neither of these are really going to work very well for the "5 recently visited websites" case.
Just in case you find it useful: I've ported gnome-globalmenu to GTK3 and gnome shell, putting the gtk menu bar into the application menu. It's the gnome-3 branch at https://github.com/gnome-globalmenu/gnome-globalmenu/tree/gnome-3. There is a screenshot (made by Wey) on https://bbs.archlinux.org/viewtopic.php?pid=964142#p964142 .
I started work on dynamic jumplists that provides the "4 recent items" and "3 other frequent items" in a list for each that communicates with Zeitgeist... We already have loggers for firefox, tomboy and anything the uses gtk.recentmanager to store its activities... you will find it in https://github.com/seiflotfy/gnome-shell-zeitgeist-extension also here is a screenshot http://seilo.geekyogre.com/uploads/2011/10/Screenshot-at-2011-10-06-223848.png
This should probably be closed now - we have app menus