Re: Menus

[Jason Pellerin <jasonp pobox com>]

At 03:26 PM 11/23/98 -0600, John R Sheets wrote:

[making the last first... ]

>Don't get me wrong.  I like the idea a lot, and think it would be a really
>cool feature to have.  However, I don't think it's practical at this point
>in time, especially with the impending API freeze.  Maybe you could
>experiment with it, with the intent of adding it to GNOME 1.1/1.2...

I should have said in my original message that this was something I was
working on as a 1.1/1.2 thing, with no intention of getting it in before
feature freeze. Given my inexperience with Gnome & the time constraints of
my day job, there's no way I could get this done in the next month, even if
I wanted to. 

So right now I'm mainly just trying to figure out how it might be done, and
experiment with implementations.

>"Jason P." wrote:
>
>> 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.
>
>Not sure how practical this would be.  Wouldn't you have to create a set of
>brand new Global Menu hints to communicate with the window manager?

That's a good point, one I hadn't thought of. But Gnome already needs a
bunch of WM hints, so I think adding a few more wouldn't be a terrible
price to pay for menus that are more intuitive & less wasteful of screen
space (in my opinion, of course). Not being an X expert, I'm not sure what
hints would have to be defined -- just something to tell the WM that the
menu window wants to be flush top/left/bottom/right? I guess it would
require new member in the _mwmhints struct [CARD32 positions?] -- which
hints the WM would respond to by moving the window to whatever it considers
top/bottom/ etc. This could be a problem if the WM doesn't notice the
hints... though I think a sequence of events like: move win to 0,0; tell WM
to position it flush top,left; note new position, if changed; dock; would
work for most cases.

>Would you implement the global menubar as one single window, or would it be
>a different window for each app, overlaid on top of each other so that when
>you click on an application, the WM has to know to bring that app's menubar
>to the foreground?

With the implementation I have in mind, each app would have its own menubar
window. Think of it as the app's menus always being torn off, but always
being in the same place relative to the root window, and hidden unless the
app has focus. I realize that this is somewhat inefficient, but the CORBA
method seems even moreso, and much harder to make happen with tweaks rather
than a massive rewrite of the whole gnome menu system. 

>If you have a single window that shows the menus for all applications, you'd
>probably have to make it a separate process. [...]

What do you see as the problems with an implementation where each app has
its own menu window (aside from positioning vs. WM issues)? Would the
hiding and showing of the menubar windows necessitate even more WM hints,
or could it be handled though appropriate signal handlers for focus/unfocus
in the app?

Thanks for the excellent feedback. 

JP