On vie, 2011-10-07 at 14:38 -0500, Federico Mena Quintero wrote: > To make a global menu possible, and robustly, we have several options:
... but first we should ask us if we actually want a global menu. As far as I can tell, the answer from the GNOME design team has been different than the one from the Unity design team. > - Have applications manage their menu, and provide a way for them to > "have their menu detached" and re-attached to the global menu bar - > think of a window manager that sniffed for menus, and put them in the > global place. This has all sorts of funky details, but you get the > idea. I do. And if the goal was to move the "classic" menu bar into the top bar, this would be the way to do it (a lot of the funky details have even been solved already to support legacy tray icons). I also agree that a GtkApplicationWindow which exposes a canonical layout (menu bar, toolbar, <app-specific space>, status bar) makes this scenario a lot more feasible. However I agree with the direction of the design team to explore options which allow applications to get rid of menu bars altogether - the fact that applications like LibreOffice, Gimp or Blender are unlikely to drop their menu bar any time soon should not stop "less complex" applications from exposing their functionality differently. This direction is hardly a peculiarity of the design team - Firefox, Chromium or Microsoft's ribbon are moving in a fairly similar direction (not saying that any of those examples should be copied directly, but if an application like Firefox can reduce its menu bar to a single toolbar button, then pretty much every GNOME application should be able to do the same). > - Have a restricted and well-defined set of functionality for menus, > that is transferable over D-Bus with no loss in behavior. As I understand it, this is the most likely approach for shell's application menu[0]. While it is somewhat similar to a global menu, its intend is quite different - it is a place to expose a limited set of common (application-global) actions, rather than a full menu bar replacement. > The first option would make a lot of sense for X11 toolkits. No toolkit > is going to be happy restricting its menu functionality to some > arbitrary subset, but they are already comfortable with letting a window > manager manage them. "Reparent the menu to an external window" is > scary, but we've been there before. I'm afraid so. Hopefully it'll help acceptance that the application menu is not actually a menu bar replacement (though it will certainly be an important part of that for applications that drop their menu bar) - the expectation that applications split their actions between those that are global to the application (to be moved to the application menu) and those that are local to the (current) window (to remain in the window) might help as well to stress that point (if we are lucky). Yeah, I'm probably just being naive ... > The second option would be very good for non-X11 platforms; with a > restricted set of functionality for menus, they could very well be made > to "just work" on MacOS, for example. I'm less optimistic there - as only a subset of the traditional menu actions would be exposed, I expect that approach to be actually more difficult to map to other platforms. This shouldn't stop us from doing it anyway, but providing an acceptable fallback on other platforms looks challenging (but necessary, if we expect application developers to make use of it) Florian [0] https://live.gnome.org/ThreePointThree/Features/ApplicationMenu _______________________________________________ gnome-shell-list mailing list [email protected] http://mail.gnome.org/mailman/listinfo/gnome-shell-list
