[mcclim-devel] menu bars

[Andy Hefner]

On 1/5/07, Christophe Rhodes <csr21 at 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.