On Fri, 2011-10-07 at 10:44 +0200, Florian Müllner wrote: > On vie, 2011-10-07 at 10:29 +0200, Aurélien Naldi wrote: >> > > I think most of the underlying tech is here already: unity use a > > protocol through which the applications describes its menu. Then it is > > up to the shell to decide how to organize them. > > Except that Canonical is in a position where they can patch > non-GNOME/GTK+ applications (Firefox, Libreoffice, Qt, Motif, ...), > while GNOME is not.
Unity's implementation has some *big* problems. It works like this: 1. The application-side code scrapes the GTK+ widgets in the menu (menubar, menus, menu items...) trying to extract things like labels for menu items. 2. The application-side code then transfers this via D-Bus to the global menu manager. 3. The global menu manager then reconstructs the menu from the labels and the info it got passed. 4. When an item gets selected, the global menu manager calls back into the application-side code (again, via D-Bus) and tells it which menu item was activated. I guess the app-side code then synthesizes the appropriate GTK+ widget signal on the original menu items. Now, for the problems: GTK+ menus are *very* flexible; they have grown over the years into something much more sophisticated than "items in a hierarchy with a label and an optional icon". You can have items in a tabular arrangement, you can insert any widget inside a menu item (and some applications take advantage of this), and you can hook into a menu in strange ways to make it do things that are quite specific to particular applications (e.g. if you need a slider in a menu item, you need to do some scary hacks with mouse grabs and event forwarding so that the behavior feels right). However, all that flexibility means that it is impossible to transfer all that information and all that behavior to the global menu manager. A GTK+ menu is just not something that you can screen-scrape and reconstruct in the general case. (I'm not saying that Unity's implementation is bad; Cody Russell (an extremely competent GTK+ hacker) wrote it, but GTK+ doesn't make things easy at all for this purpose.) To make a global menu possible, and robustly, we have several options: - 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. - Have a restricted and well-defined set of functionality for menus, that is transferable over D-Bus with no loss in behavior. Either option would be *much* easier if GTK+ finally implemented a GtkApplicationWindow with actual space for a menu bar - *the* menu bar, not just a random menu bar that happened to be placed by the app in the conventional place within its window. I'm sure there is a bug filed for this; you may want to look for it and see the progress there. 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. 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. Federico _______________________________________________ gnome-shell-list mailing list [email protected] http://mail.gnome.org/mailman/listinfo/gnome-shell-list
