Re: Suggestion: Remove the Window Title Bar

[Federico Mena Quintero <federico gnome org>]

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