On Tue, May 06, 2003 at 11:54:59PM +0200, Wolfgang Thaller wrote:
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.
I agree, which is why I didn't want to go into too much detail (which would obscure the main idea). My current idea (for the "normal" cases) is something like this: Each menu command would specify its parent menu name and an ordering index. When a menubar is composed of a set of commands, it gets all the menus that are needed, and then the commands are placed in these menus according to the order of their indices. This method will only work if the relative ordering of two commands is the same in all cases, which seems reasonable to me, but may be considered too limiting.
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).
Absolutely, I think there should be the ability to deal with special cases, and some standard special cases (e.g. Preferences) should be predefined.
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...
Good points. I am convinced that the idea of using the window-parent (if it exists) to inherit menu-bars was ill-conceived. -- David Roundy http://www.abridgegame.org