[mcclim-devel] Listener menus

[Andy Hefner]

On 1/3/07, Christophe Rhodes <csr21 at cantab.net> wrote:
> "Andy Hefner" <ahefner at gmail.com> writes:
>
> > Note that the menu-item presentation type is implied by the spec
> > within the definition of draw-standard-menu
> > (http://www.stud.uni-karlsruhe.de/~unk6/clim-spec/25.html#_1357).
>
> Yeah, I discovered that.  But actually my patch does this right --
> because there is already a define-presentation-type menu-item in
> mcclim, it just got clobbered by the class definition.

Interesting, that is not the behavior I'd expect, but then I also
never thought allowing CLOS classes to be considered presentation
types was a good idea (but the spec seems to disagree).

> > Is it possible to simply define a menu-item-to-command translator with
> > a higher priority which would override the translator currently
> > stealing the menu-item?
>
> I think that this isn't necessary, and that my last patch is the Right
> Thing as well as actually working.

By virtue of simplicity, your patch wins. However, I wonder if
defining such a translator means that we can rip out the toplevel
magic about creating an input-context for menu items. Along those same
lines, maybe we ought to just present them as commands, so they are
directly applicable. It doesn't seem useful presenting anything as a
menu item (unless you are writing an editor for menus), except perhaps
as a way to control the highlighting style, and in that case it
wouldn't be the innermost presentation anyway.

Anyway, your patch sounds good to me.