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<http://lh3.googleusercontent.com/_1QSDkzYY2vc/TV1ykj9zUgI/AAAAAAAADA4/wb3dfkvSVOg/gedit_menu.png>)
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

Reply via email to