Re: Suggestion: Remove the Window Title Bar

[Florian Müllner <fmuellner gnome org>]

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