On 1/3/07, Christophe Rhodes csr21@cantab.net wrote:
"Andy Hefner" ahefner@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.