[GUI] idea regarding mac menubar issue

[Wolfgang Thaller]

David Roundy wrote:

> Hello GUI people! (I figure a greeting is in order as I'm new to this
> list...)

Welcome!

>   I had an idea a few days ago, and am not sure if it's workable,
> but figured I'd better mention it before I forget it.  I understand 
> (from
> browsing the archives) that it's perhaps a bit early to be debating the
> intricacies of menu events (or callbacks or whatever) for CGA, but 
> didn't
> want to forget the idea...

We probably shouldn't decide anything yet, but tossing around a few 
ideas can't hurt...

> There are several classes of menu commands:
>
> 1) Always relevant, handled by the lobby: e.g. New Table, Quit,
> Preferences.
> [...]
>
> 2) Only relevant to a table: e.g.  Close Table, Claim Tricks, Show 
> Score,
> Show Last Trick.
> [...]
>
> 3) Relevant to either window: e.g. Copy, Paste (since they have chat 
> boxes
> you could copy into).

Copy and Paste (and a few other commands, mostly from the "Edit" menu) 
are relevant whenever a widget that supports copy & paste is in focus; 
this is even the case when an application-modal dialog is active. An 
application-modal dialog disables all menu commands except copy, paste 
& co.

In most applications (perhaps not in your example), there is also a 
fourth class:

4) Relevant to the entire application, even if there is no open window 
at all (this is a situation that's not even possible on other 
platforms). Examples include "New", "Open" and "About..".

All MacOS-specific toolkits and OO frameworks handle menu commands 
about like this:
A "menu command" event is first passed to the widget that has the 
keyboard focus; If that widget doesn't handle the menu command, it is 
passed on to the widget's container, and so on. If the window doesn't 
handle it, it is usually passed to the "application object"; if the 
application has multi-window documents, it might be passed to a 
"document controller" object before that.
So the "Copy" and "Paste" commands would be handled by a text entry 
widget; the "Close" command would be handled by the window; the "Save" 
and "Save As" commands would be handled by the window or by the 
document controller; and the "New", "Open", "About" and "Preferences" 
commands would be handled by the application object.
Can such a scheme be adapted for cross-platform use? I doubt that 
simple callbacks attached to the menu items would do the trick for 
MacOS style menu bars.

> My Idea
> =======
>
> At the beginning of the program (whenever the menubar gets created) the
> program needs to list every menu command it wants to recognize, each of
> which will have an appropriate parent menu together with some 
> information
> to help order the contents of the parent menu. [...]

Sounds nice... if it can be made to work. It's not trivial to come up 
with a scheme for this "automatic menu bar composition"; but if it 
worked that would be great, as I don't like special cases either.

That "information to help order the contents" should probably be 
predefined in the CGA backend for standard commands; so that if I say 
"I want a preferences command", it would automatically be in the right 
place; if I say, I want a "Do Some Other Stuff" command, I would have 
to say where it has to go (and it's unlikely that different platforms' 
standards on where to put those extra commands differ too much).

> One final issue is it seems that windows should have (perhaps optional)
> parents, in order for the menu events to get appropriately routed on 
> the
> mac.  It would seem that if a window with no menu is in front (such as 
> my
> score window, which just displays the score for a specific table), the 
> menu
> commands of its parent should be active, and should get routed to the
> parent.  It seems that the easiest way to implement this would be if 
> each
> window had a parent, although one could also require that these windows
> specifically mention whose menubar they want to be displayed (or risk 
> all
> but global menu options being disabled).

Perhaps ... but commands that are specific to a certain window _should 
not_ be enabled when another window is in the foreground, even if that 
other window handles no commands of it's own.
In some cases, both windows may belong to the same logical group of 
windows --- for example, both windows might belong to the same 
"document" or to the same "game" --- in that case, commands that apply 
to the "document" in general should remain enabled, but not commands 
that relate specifically to the main document window.
There might be cases where it's more confusing to the user to enable 
inappropriate commands than to disable some commands that _could_ be 
enabled.

Anyway, I wouldn't call this a "parent window"; so far, I know of one 
case where we will most definitely have the notion of a parent window, 
and that case is window-modal dialogs. However, a window-modal dialog 
won't use it's parent window's menu bar; rather, it would disable all 
but the application-wide commands (About, New, Open,...).
So the name "parent window" is already taken by something with 
different semantics...

Cheers,

Wolfgang