Just a note: global menu looks like it was teared from an application off. BTW, mega menus look very pretty (http://live.gnome.org/Design/Whiteboards/Menus). It is sad that there are so much items in "But" section.
On Fri, Oct 7, 2011 at 11:47 PM, Gavin Engel <[email protected]> wrote: > Federico, that is a very interesting read. One thing I wanted to point out > is that there is a pseudo-Global-menu extension for > GNOME: http://www.webupd8.org/2011/09/get-global-menu-in-gnome-shell.html > What do you think? Also, is the placing menus in the window titlebar > (example) just as tricky to accomplish as the Global-menu system you > described? > > On Fri, Oct 7, 2011 at 12:38 PM, Federico Mena Quintero <[email protected]> > wrote: >> >> 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 > > > _______________________________________________ > gnome-shell-list mailing list > [email protected] > http://mail.gnome.org/mailman/listinfo/gnome-shell-list > > -- Sergey Zolotorev _______________________________________________ gnome-shell-list mailing list [email protected] http://mail.gnome.org/mailman/listinfo/gnome-shell-list
