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.