Hi,
The attached restores working menus to the Listener. (It's not completely clean; I'll try to explain why).
The first thing to do, done in the middle hunk of the three-hunk patch, is to put back the listener-view specializations to the interactor and the pointer documentation. (The latter isn't necessary, but I think it's right anyway).
The first hunk is the magical one: it defines a command-or-form accept method which treats menu-items specially. The problem is that a menu-item is a perfectly good form, at least according to the various presentation translators around; therefore, the command-or-form input context "captures" the menu item. I'm not sure that this is ever desired behaviour, but it's certainly not desired behaviour inside read-frame-command of the listener, so we reintroduce an input context for menu-item inside the command-or-form context, and throw to the outer context handler established by the McCLIM-provided read-frame-command :around method.
As I say, I'm not sure that it's ever desireable for 'expression or 'form input contexts to capture menu-items; if it isn't, then probably mcclim itself ought to prevent it from happening, maybe by a similar trick inside the system accept methods? It all looks a bit horrible, though. It's not great for the user as it stands, though, because as far as I can tell there's no standard menu-item presentation type -- the one that McCLIM implements is good, but it's not in Gilbert's annotatable spec -- and the contents of *input-context* are explicitly unspecified.
The third hunk of this diff is an alternative approach, handling menu-items specially if they're returned from read-frame-command. This feels clunkier somehow -- for instance, the menu-item objects are printed at the repl -- but seems to violate fewer abstractions.
Comments?
Cheers,
Christophe
PS: when I apply this patch and click on a menu item for, say, Show Class Subclasses, the resulting dialog box eats my first keystroke using Drei, but not using Goatee.
Christophe Rhodes csr21@cantab.net writes:
As I say, I'm not sure that it's ever desireable for 'expression or 'form input contexts to capture menu-items; if it isn't, then probably mcclim itself ought to prevent it from happening, maybe by a similar trick inside the system accept methods?
I had an idea on the way home from work regarding this. If it is the case that menus shouldn't be captured by form and command-or-form accepts, then I think what needs to happen is that menu-items shouldn't have translators to form or expression presentation types. Does that sound more plausible?
Cheers,
Christophe
Christophe Rhodes csr21@cantab.net writes:
Christophe Rhodes csr21@cantab.net writes:
As I say, I'm not sure that it's ever desireable for 'expression or 'form input contexts to capture menu-items; if it isn't, then probably mcclim itself ought to prevent it from happening, maybe by a similar trick inside the system accept methods?
I had an idea on the way home from work regarding this. If it is the case that menus shouldn't be captured by form and command-or-form accepts, then I think what needs to happen is that menu-items shouldn't have translators to form or expression presentation types. Does that sound more plausible?
(I think so. Patch attached.)
Cheers,
Christophe
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).
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?
On 1/3/07, Christophe Rhodes csr21@cantab.net wrote:
Christophe Rhodes csr21@cantab.net writes:
Christophe Rhodes csr21@cantab.net writes: I had an idea on the way home from work regarding this. If it is the case that menus shouldn't be captured by form and command-or-form accepts, then I think what needs to happen is that menu-items shouldn't have translators to form or expression presentation types. Does that sound more plausible?
Or, even better, define such a translator at the default priority, and lower the priorities of the various *-to-[form,expression] translators, defined in builtin-commands.lisp, in order that they never compete with an explicitly defined translator at the default priority.
Speaking of such things, I'm curious what happens when you accept '(or type-1 type-2), and have applicable translators to both type-1 and type-2 for some presentation. As currently implemented, I'd guess the translator to type-1 always applies, even if it has lower priority than the translator to type-2. I wonder if this is intuitive.
On 1/3/07, Andy Hefner ahefner@gmail.com wrote:
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?
"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. Defining the menu-item class with a different name (%menu-item) leaves the presentation type untouched -- and that presentation type doesn't inherit from expression or form, and doesn't have a translator to expression or form. So everything comes out right.
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.
Cheers,
Christophe
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.
"Andy Hefner" ahefner@gmail.com writes:
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.
Okay, I've committed it.
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.
I think that menu-items by default should probably not translate to commands. Why? Because I think that it's legitimate for an application to do (accept 'command) when not planning to run it immediately (maybe to batch it up, to send to a remote process, or something); under those circumstances, I would expect selecting something from the application's menu bar not to fulfil this accept but instead to run its own command directly.
It might make sense for individual applications to specify that they would prefer their menu items to be presented as commands; I don't know whether the CLIM spec documents any way of achieving that.
Cheers,
Christophe
To: "Andy Hefner" ahefner@gmail.com Date: Thu, 04 Jan 2007 09:19:04 +0000 From: Christophe Rhodes
I think that menu-items by default should probably not translate to commands. Why? Because I think that it's legitimate for an application to do (accept 'command) when not planning to run it immediately (maybe to batch it up, to send to a remote process, or something); under those circumstances, I would expect selecting something from the application's menu bar not to fulfil this accept but instead to run its own command directly.
I disagree. A menu is nothing more than a way of grouping and presenting a bunch of commands, no different than an button box. In your example, if the command I wanted to accept was "Save", picking it off the "File" menu seems like the way to do it.
Mike McDonald mikemac@mikemac.com
-
Andy Hefner -
Christophe Rhodes -
Mike McDonald