hi; On 4 July 2013 22:18, Michael Catanzaro <[email protected]> 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/ _______________________________________________ desktop-devel-list mailing list [email protected] https://mail.gnome.org/mailman/listinfo/desktop-devel-list
