[mcclim-devel] menu bars

Christophe Rhodes csr21 at cantab.net
Fri Jan 5 16:08:33 UTC 2007


"Andy Hefner" <ahefner at gmail.com> writes:

> On 1/5/07, Christophe Rhodes <csr21 at cantab.net> wrote:
>> The surprise is that it isn't possible to do this to the contents of
>> the menu bar itself: the menus there are fixed when the pane is
>> instantiated, I believe.  So my question: is this intentional?  Is it
>> desireable?  (And what does Legacy CLIM do? :-)
>
> I can't object to this behaving in the expected way, if you want to
> take the effort to make it work. It makes sense to me. 

OK.  (No promises yet: my main use case is the one that already works
:-)

> On the other hand, since a command table (and its menu) are shared
> global resources rather than part of the local state of a frame, I'm
> having trouble imagining uses other than resolving the obvious "I
> just added a new command, why can't I see it?" situation, which
> shouldn't arise often anyway if you organize your commands into
> logical menus.

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).

I quite agree that uses of this facility would have to ensure that
they modify a frame-specific command table and not a global one... Oh.
For some reason I thought it was possible to have anonymous command
tables, as in the GENERATE-PANES method in
MAKE-SINGLE-GENERATE-PANES-FORM in frames.lisp (naming it with NIL),
but maybe this isn't in fact allowed...

Cheers,

Christophe



More information about the mcclim-devel mailing list