On 7/7/06, Troels Henriksen athas@sigkill.dk wrote:
"Andy Hefner" ahefner@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.. =/