On 1/5/07, Christophe Rhodes csr21@cantab.net wrote:

Well, one use case is for applications (such as gsharp and climacs), with some notion of input state: for instance, if in lyrics mode in gsharp, there should be a lyrics menu in the menubar, where there probably shouldn't be if in notes mode. Similarly, if in Lisp/SWINE mode in climacs, there should probably be menus for lisp interaction, which shouldn't be there for a buffer in Fundamental Syntax. (GNU Emacs, at least, performs manipulations of its own menu bar in much this way).

Interesting. I'd never considered the possibility of using anonymous command tables, but the command table functions seem to support the concept. I'm not sure I understand the problem in using them - if the only hangup is how to sneak it through define-application-frame to make all the frame instantiating grunge cooperate, you can always write your own read-frame-command, or extend mcclim.

Being able to add and remove menu items like this sounds useful and is exactly the sort of low level interface I ought to like, but to actually use it in an application is probably wrong in the same way that making frequent use of (setf command-enabled) is stupid and wrong (compared with using mgr's much nicer conditional-commands extension).

Here's an alternative approach I dreamed up a while ago which (I think) addresses the uses you've described: Put the menu bar under the control of accept (or possibly read-frame-command), driven by the current input context. It would combine the menus for every command table in the current input context via some protocol, updating the menu items when the input context changes (if necessary).

I don't know how the command reading is done in the applications you mention, but I'd expect you have a command table for commands on the application instance (Quit, etc), one or more command tables for the current buffer and its syntax/mode, and yet another for the current input mode, all of which should be part of the current input context (or somehow inherited together). So, commands from any of these tables should satisfy the accept done by read-frame-command, and as such our extension would merge their menus to populate the current menu bar.

Recalling your example the other day of reading a command you don't intend to accept, perhaps putting this under the control of read-frame-command makes the most sense (rather than occuring in response to every accept of 'command, regardless of what you intend to do with the command).

If implemented, this ought to be unnoticable unless the application is highly modal. In particular, it should not flicker every time through the command loop. :) I'd also expect that entering accepting-values should also not cause my menu bar to change, so it shouldn't apply unconditionally.