Re: Menus

["Khimenko Victor" <gnome khim sch57 msk ru>]

22-Nov-98 16:58 you wrote:
> 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.

May be yes, may be no. In fact there are a lot of other possible versions
(like sun's: left click for default menu action, right click for opening
submenu). And toolbars. Plus customizability (mainly for toolbars but for
menu this also could be usefull): for example the single most usefull menu
item for me in Netscape (View->Encoding) is hardly ever usable at all for
English-speaking peoples. If I'll have three buttons on toolbar: KOI8-R,
windows-1251 and iso-8859-1 I'll be happy but for non-russian users it's
not needed (or needed other buttons like three types of chinese :-). So
customizability of menus AND (even more important!) toolbars is great.
Also important is possibility to move such theme from one user to other.
Plus there are will be some compond documents in the future. In this case
menus from two (or more) applications should be combined. There are A LOT OF
possible variants to do this (and current MS's approach is not great IMO:
for example I'm could not change location in embedded netscape document via
menu since menu File is from Word, not from Netscape) and noone is perfect.
If this will be moved in separate plugable engine this problem will be solved
(you could choose one of meny engines or create your own if you are smart
enough). Of course this will require big rework of menu/toolbar subsystem and
may be does not worth it... But since GNOME is GNOME (not good desktop NOW
but great desktop for the FUTURE) looks like a good idea...

> 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


> --
>          To unsubscribe: mail gnome-list-request@gnome.org with
>                        "unsubscribe" as the Subject.