Re: [Usability] [Ayatana] The Future of Window Borders, Menu Bars, and More

[Milan Bouchet-Valat <nalimilan club fr>]

Le lundi 30 août 2010 à 22:19 +0800, Allan Caeg a écrit :
> Hello,
> 
> It would be nice if we can put menus (or alternatives like the Firefox
> button) on window borders, but there could be too many technical
> issues, especially because of different window managers.
> 
> Context-specific menus would also be nice, but I don't know if they
> can be done in the near future.
> 
> Maybe, it's more feasible to let the environment choose how it's
> supposed to show the menu bar (an environment can even display it on
> the window border, but it shouldn't be imposed as a standard). We can
> use the Unity as an inspiration. It will (or already does) hide the
> menu under the window title in the panel unless invoked with mouse or
> Alt. The AppMenu for GNOME Shell could be the solution for the GNOME
> environment. Maybe, we should work on that idea to come up with the
> pixel-efficient solution. 
> 
> Thoughts?
I think that for GNOME, the idea of menus in window border should be
considered from the perspective of the Shell. As you said, there's
already the Application menu, which could be used for things like that -
e.g. an "Open containing folder" command as Federico suggested [1].

If the Application menu is not considered in the end as the right place
for other commands, adding them to a menu placed inside the window could
be done more easily from the Shell than from plain Metacity/Mutter,
since they can be created using Clutter from JavaScript.

But in both scenarios, these commands would have to be standard, since a
D-Bus protocol would need to be designed to allow apps to influence what
the menu is showing. That's why the "Open containing folder" idea is
interesting: apps only have to tell what file they are working on, and
the menu can provide several actions on it. No need for a complex and
changing D-Bus protocol.

So I think you should raise this discussion on #gnome-shell, or on
gnome-shell-list, or better, on both, since from a design and technical
perspective it would be better to implement this there. But the ideas I
exposed are only rough suggestions... ;-)


Cheers

1: http://people.gnome.org/~federico/news-2010-08.html#which-document