Re: [Usability] Mac-style menubar in GNOME

[Matthew Paul Thomas <mpt myrealbox com>]

On Sep 13, 2006, at 2:47 AM, Zoran Rilak wrote:
> ...
> I'm working on a simple panel applet that would provide functionality
> similar to Mac's menu bar.  Adding the applet would cause most menu 
> bars to automagically disappear from their respective windows and 
> migrate into the applet's area.  Removing the applet would restore 
> menubars to their parent windows.

This is *excellent* news. I warn you, though, it won't be "simple". :-)

> Obvious and contrived implementation issues aside, I would like to 
> probe the list for any and all comments on the potential usability of 
> such an applet (and analogously its potential testing user base).
> ...

Short-term advantages:
*   Much faster, because the menu target area is near-infinitely high.
*   More compact, because there is only one menu bar on screen at once.
*   More predictable, because 99% of menus open down and to the right,
    regardless of where the window is.
*   Less confusing, because multiple menu bars on screen simultaneously
    sometimes result in people clicking the wrong one.

Long-term advantages:
*   More consistent, because Nautilus can provide a menu bar for the
    desktop just like it does for folder windows.
*   More consistent, because "Edit" menu items (Undo, Redo, Cut, Copy,
    Paste, Delete, Select All, Check Spelling) can be made available for
    text fields in dialogs as well as for normal windows.
*   More consistent, because programs won't do things like not having an
    "Edit" menu (e.g. Gaim) just to save horizontal space.
*   More flexible, because programs with narrow windows can introduce
    full sets of menus without resorting to abbreviations (e.g. "Xtns"
    in Gimp), big grey parent windows (e.g. Photoshop for Windows),
    chevrons, or wrapping.
*   Simplifies the whole interface, because menus being easier to use
    reduces the number of controls desired in toolbars and elsewhere.

Short-term disadvantages:
*   Requires clicking in a window before using its menus.
*   Can be slower, if your pointing device is (mis)configured such that
    you can't reach the top of the screen in a single motion.
*   Prevents using hover-to-focus (analogous to how CUA keybindings
    prevent using Emacs keybindings).

Long-term gotcha:
*   For a global menu bar to achieve widespread use, XUL (Firefox and
    Thunderbird) and OpenOffice.org will both need to hook in to it.
    (Fortunately, there is precedent for this in XUL and NeoOffice on
    Mac OS X.)

Suggestion:
*   When a child window without a menu bar (e.g. a dialog) is focused,
    instead of blanking the menu bar, show the menus of the parent
    window but disable them all. This will make the menu bar look more
    stable.

Please keep us up to date with how you're getting on, and/or publish 
the code so others can help out.

Cheers
--
Matthew Paul Thomas
http://mpt.net.nz/