Menus

["Jason P." <jasonp pobox com>]

Over on the gnome-gui list, the topic of 'themable' menu look n' feel
has gotten a lot of discussion lately. There seems to be some consensus
that it would at least be interesting to explore supporting Mac &
NeXT-style menubars in Gnome. I posted a message there last week saying
that I was interested in trying to make that happen, and nobody said
'Don't you dare!', so I've been looking into things. This message is a
proposal, and a request for discussion and assistance. (It's a little
long, so if you're not a menu- or theme-nerd, you might want to skip
it.)

The big disclaimer: I'm a newbie when it comes to Gnome. I've read
through the parts of the source that seem relevant, and I run it on my
home machine, but I haven't written any Gnome apps, or yet contributed
any code to Gnome itself. Take what I say, especially about
implementation details, with as much salt you want: I might be
absolutely full of it (not salt).

Anyhow, on with the 'show':

Part 1 - What? Menu styles? Why?
--------------------------------

The basic idea, as mentioned above, is that Gnome have (at least) 3
global options for the look n' feel of menubars:

1. The current (what I think of as 'Motif/Windows style'): menubars
embedded in their parent windows, optionally with capacity to be dragged
out by user.

2. 'Mac style': a single, global menubar, across the top of the screen.
Personally, I like this style of menubar best: it's easiest (again, for
me) to use, least confusing in practice (I have a bad habit of clicking
the wrong 'File' menu when I have alot of windows open on screen), and
seems conceptually cleaner. One application/window has the focus; one
set of menus is active; menus are always in the same place.

3. 'NeXT style': NeXT's global, draggable vertical menubar has many of
the same advantages of Mac style. And a lot of people out there swear it
is easier to use, takes up less screen space, and makes more sense in a
multi-head/multi-desktop world than a Mac-style menubar, which may well
be true. Enough people like it that I think it ought to be supported.

Why themes? Why not just switch the whole system to one style or
another? Well, I like Mac menubars better. And generally, UI gurus like
Tog seem pretty convinced that global menus work better for most users.
But I'm sure there are lots of people who swear by Motif/Windows style
menubars, don't want to drag their mouse halfway across creation just to
get to the stinkin' menubar, etc. -- so menu style should be implemented
as a user option, not something the system forces on you. Mandating one
way or another to do something doesn't seem right to me. (But then I
mostly make my living writing perl scripts, so you know where that idea
comes from.)

Part 2 - fuzzy thoughts about how to do it
------------------------------------------

The way I see it, there are two ways to make menu themes happen:
extending the current menu system, or replacing it with something akin
to GTK-themes, wherein the actual menu look n' feel would be handled by
a set of menu engines (mac-engine, next-engine, etc.)

The second approach is obviously the more flexible -- since the whole
menuing system would be controlled by an arbitrary engine, somebody who
loved pie menus, eg, could write up a pie-engine. Or whatever.

But I think, after going through the code, and giving it a few days of
serious thought, that menu engines would be overkill, and a nightmare to
implement right. And I don't know if the level of flexibility that such
a setup would deliver would be worthwhile in general, worth the
commitment of time it would take to make it work, or beneficial to the
user, in the end. What do other people think? Is maximum flexibility
desireable in itself, or is it better to have 'just enough' flexibility
(for some definition of 'just enough')?

The first approach, extending the current menu system in GTK (and in
gnome-app's helper routines), seems to me, at least, the better path.
With some tweaking of the handlebox & menubar classes in GTK, and
gnome-app and friends, I think the current system can be made to look
and act like Mac or NeXT menus. To me this looks like 90% of the benefit
of menu engines, for much less work.

Part 3 - somewhat less fuzzy thoughts about how to do it
----------------------------------------------------------

The goals of the extended menu system would be:

1. Support current menu style (Done!)
2. Support a global menubar, or the appearance & functionality of a
global menubar - those being:
        * A menubar which is (or begins) in the same screen location for
all
windows, and in which
        * Only the menus of the currently focused window are visible.
3. Support vertical menubars.

The way I would propose doing this is:

1. Extend gtkhandlebox to support 'docking' on the top, sides, and
bottom of the screen area. This would involve adding to the singals enum
(SIGNAL_CHILD_UNDOCKED, SIGNAL_CHILD_DOCKED, _ -- also ..._DOCKED_TOP,
_LEFT, etc?), adding code to emit those signals at all, emit them at the
proper time, and decide whether to emit them. The _GtkHandeBox struct
would also have to get another member (guint child_docked), and, to
support docking of toolbars as well as menubars, a member/members
denoting the current top, left, bottom, and right dock points. (If
toolbars can be docked as well, then we've got to take into account,
when docking/undocking a menu- or tool- bar, the fact that another bar
may be docked above or below us. Code to reorder docked items as other
items come undocked would also have to added, probably to gnome-app.)

2. Extend gtkmenubar to optionally stagger child menus vertically
instead of horizontally.

3. Extend gtkmenubar to correctly interact with gtkhandlebox in the
docked case (eg. for Mac menubar, making width equal to screen width).

4. Extend gnome-app to catch focus signals and show/hide docked menubars
correctly. (This one I'm not sure about-- is gnome-app the right place
for that code? I don't quite understand how Gtk handles this stuff, and
I'm not sure how much depends on the cooperation of the window
manager... )

5. Extend gnome-app to set default menu position/style from config
options -- which should be global, but capable of being overridden by a
theme.  There should be a menu page in the System > 'Look and Feel
properties' notebook, with options for menu position and direction
(horiz/vert.); but equally, somebody should be able to design a 'MacOS'
Gtk theme, and have that theme set the default menu style to Mac-like.
(Exposing my ignorance again, I don't know the specifics of how Gnome's
config options work, so I don't know how hard this one will be to do
right)

6. Do something about the case when no application windows are open.
What happens to the menubar then? System menus? It just goes away?

Part 4 - Help?
--------------

As I said, I'm new at this. I think I have a pretty good general idea of
what needs to be done, but clearly, I'm fuzzy on a few of the details.
If someone with more knowledge and experience would point me towards
places where I can find out about the things I don't know, it would be
greatly appreciated. And if anyone else wants to get involved in
planning and coding this project, well, that would be really great. At
this point, I'm throwing out these ideas (which didn't originate with
me, by any means -- I've just gone into a little more depth on the issue
of how it might be done) for public discussion, flaming, etc. If I
inspire somebody with a few more clues than I've got to go out and code
it over the weekend, cool. If I inspire someone to call me a walnuthead
and tell me to go back and read the source some more, well, that would
be less cool, but at least it would be a kind of progress.

Thoughts? Opinions?

-- JP