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.