[mcclim-devel] Patch for menu-choose.lisp

[Andy Hefner]

On 7/7/06, Troels Henriksen <athas at sigkill.dk> wrote:
> "Andy Hefner" <ahefner at gmail.com> writes:
>
> > Sounds good, but I still think we should really get rid of
> > menu-choose.lisp at some point and reuse the implementation of menus
> > in menu.lisp, which is (was?) much more complete.
>
> AFAIK, menu.lisp is mostly concerned with command menus, and I believe
> tt would make more sense to build these via the facilities provided by
> `menu-choose' than the other way around. If nothing else, because
> `menu-choose' supports a huge amount of options that would be quite
> difficult to support unless it is built into the basic implementation.

Perhaps. 2/3 of menu.lisp is a generic implementation of menus as
gadgets, not relating to command menus specifically.
frame-manager-menu-choose is intended to allow use of native window
system menus, and in that respect using the menu.lisp implementation
seems just as valid as throwing a bunch of presentations in a
stream-pane. On the other hand it is true that not all of the keywords
to menu-choose translate, particularly those relating to table
formatting, but I don't think it would be a terrible amount of work to
support these using a table-pane. Others, such as those related to
caching, seem ignorable.

Maybe it makes sense to implement them the other way around (command
menus in terms of menu-choose). Maybe it doesn't. Menus have some
gadget-like characteristics (such as opening submenus) that we could
in theory implement as presentation actions. There is some sense in
choosing the simplest implementation strategy that can support the
required features, and on X11 there is no specific reason to prefer a
gadget-based approach simply because it most closely resembles how
other toolkits are implemented. However, I have doubts about the user
experience resulting from more clever implementations that try to
leverage higher level CLIM features. My general opinion is that the
higher you ascend the CLIM stack, the more bogus and unfinished the
design gets, and the more of a fight against the system it becomes to
get specific desired behaviors.

I personally dislike the menu-choose.lisp menus because they don't
feel tolerably 'native', even to the lowered expectations of an X11
user. Finding a way to hack the highlighting style to look like a
normal menu (I've never been a fan of the CLIM "draw a box around it"
highlighting) would be an improvement. I have reservations about an
approach that likely requires defining gestures and using presentation
actions to implement the required behavior. You might be able to
define a presentation action that opens a submenu in response to the
select gesture, but how do I get the traditional behavior where
submenus open/close automatically in response to mouse motion, short
of dropping down to writing event handlers?

Fortunately, the path of least resistance -- applying your patch and
paying no further mind to the menus for another couple years -- works
for me.

> <antifuchs> Athas: very good question. counter-question: can we
> release mcclim as-is, or should we try for a re-freeze in a few weeks?

Before release, we should definitely restore the forward-referencing
workarounds that Xof removed, as they're still needed for CMUCL. I
have a patch against mp-nil.lisp that I'd like to get in too, and I'll
probably check that in tonight. It will break gtkairo on unithread
lisps, and although the patch to fix it seems trivial, I'm not
enthusiastic about entering the brave new world of gtkairo in order to
test it.. =/