Reflections on menus items and #queryCommand: - future thoughts - Smalltalk

Tim,

> However the #queryCommand: approach is too much of a next leep (in fact
> it smells a bit of case statement a bit too much for my liking) - I
> don't understand why the menu compsoser doesn't let you fill in an
> EnableBlock and a CheckBlock (that answer true) similar to how icons are
> done for TreeLists. This seems like a much easier next step in the
> progression of becoming a dolphin master. (I seem to recall this is how
> VA does menu's). I agree its not as flexible - but its a lot easier -and
> I think thats something to learn from our Rails friends.

FWIW, I have at times exploited the switch-like nature of
#queryCommand:. It is common for groups of commands to depend on the
state of other presenters/views (e.g. selection or lack thereof in a
list). In those situations, one can test the method argument against
the relevant collection of selector names and act accordingly. Being
forced to set blocks would (I _think_) force duplication.

The main point is that the command routing system enables/disables the
command/selector, not the widget, allowing menus, buttons and toolbar
buttons to be controlled by code in one place ("say it once"). One
would have to create a place for it outside of the various views
(ungainly), or decide to charm a particular view (baaaaaaad). I suspect
more than a few pints were consumed arguing the merits, and I think OA
got it right.

One thing that should be done is to add a class like Once to the image,
and the command routing docs should be updated to describe its use in
debugging the methods.

Have a good one,

Bill


--
Wilhelm K. Schwab, Ph.D.
bills@anest4.anest.ufl.edu

Hi Bill,

> FWIW, I have at times exploited the switch-like nature of
> #queryCommand:. It is common for groups of commands to depend on the
> state of other presenters/views (e.g. selection or lack thereof in a
> list). In those situations, one can test the method argument against
> the relevant collection of selector names and act accordingly. Being
> forced to set blocks would (I _think_) force duplication.

Thats my point - mostly you don't need this, and the complexity that queryCommand:
in its current incarnation presents its quite a bit to get your head around
from the simple idea that menu items are just objects.

Still I reckon you could keep it - but provide the intermediate step of menu
items having the relevent enablement blocks for a much simpler experience.

For thorny problems you can then explore the glory of queryCommand: and routes
- even then I bet you could add an object to a menu that all all menu items
could share and reference from their blocks of code - thus refactoring it
nicely. In fact looking at the existing #queryCommand:'s in the image there
is lots of duplication in all of them.

Still I suppose its a done deal at the moment - I have more energy for other
things, and I still have that promise to get the CruiseControl stuff published
for Esteban.

Tim

Tim,

I think the modification you want is not that hard to do. A CommandMenuItem
currently knows a CommandDescription (see the CommandMenuItem class instance
creation category). If I understood you right, what you want is to have a
ClosedCommandDescription instead, which has it own #queryCommand block (you
would put in that block what is now beeing put in the presenter for that
particular command).
I think that the commands framework already supports what you are asking for
(I may be wrong though), but you would need to allow a CommandMenuItem to
choose between CommandDescription and ClosedCommandDescription, and to
modify the MenuComposer to let you do the edition.

best regards
martin

Martin Rubi wrote:
> Tim,
>
> I think the modification you want is not that hard to do. A CommandMenuItem
> currently knows a CommandDescription (see the CommandMenuItem class instance
> creation category). If I understood you right, what you want is to have a
> ClosedCommandDescription instead, which has it own #queryCommand block (you
> would put in that block what is now beeing put in the presenter for that
> particular command).
> I think that the commands framework already supports what you are asking for
> (I may be wrong though), but you would need to allow a CommandMenuItem to
> choose between CommandDescription and ClosedCommandDescription, and to
> modify the MenuComposer to let you do the edition.
>
> best regards
> martin
>
>

Tim,

It just occurs to me that what you're trying to do may be similar in
some ways to what I've been doing with an SUnit Browser plugin for the
Dolphin class and system browsers. Basically, I want to be able to
extend the existing menus in the IDE tools and route new commands
directly to the new plugged in classes. With the standard command
framework this can be a little tricky (as I think you may have spotted)
since:

1) You can't dynamically extend any queryCommand: handlers that are
already in place because of their "switch-like" nature.

2) You may need to interfere with the command routing to ensure that the
plugged in object can successfully receive the new commands even if it
is not in the current focus chain.

There is an example in OAIDEExtensions>>extendClassComandMenu: that
might prove useful. As Martin suggests, this shows how to use a
ClosedCommandDescription to route new commands directly to the class
that implements them and, at the same time, provides it's own
queryCommand block for dynamically enabling/checking the commands.

You can also add accelerator keys to the ClosedCommandDescription (using
£acceleratorKeyString so that the new commands can be triggered
directly from the keyboard, although this should only really be done if
the command is to go into a menubar menu (i.e. not a context menu).

The Unit Tests plugin for the browsers will be in D6.1 (which we'll try
and get out for Xmas). Basically, when the plugin is installed, one can
run the available tests for a browsed class by typing Alt+R and get a
traffic light response in a similar manner to the way the Code Mentor
currently displays it's results. Maybe I'll post some screenshots when I
have a moment.

Best regards

Andy Bower

Hi Andy,

> There is an example in OAIDEExtensions>>extendClassComandMenu: that
> might prove useful. As Martin suggests, this shows how to use a
> ClosedCommandDescription to route new commands directly to the class
> that implements them and, at the same time, provides it's own
> queryCommand block for dynamically enabling/checking the commands.


I'll take a look there - I can probably improve how I managed to get things
to work now that I've taken a step back from it. Your comments sound very
much like what I was trying to do (although in my case, I could modify the
#queryCommand: however it all seemed to get a bit messy and what you hint
at seems like a cleaner more general approach)

> The Unit Tests plugin for the browsers will be in D6.1 (which we'll
> try and get out for Xmas). Basically, when the plugin is installed,
> one can run the available tests for a browsed class by typing Alt+R
> and get a traffic light response in a similar manner to the way the
> Code Mentor currently displays it's results. Maybe I'll post some
> screenshots when I have a moment.

Hey that sounds really cool! A little "wow" buzz around christmas would make
this years hard work all the more satisfying - I already owe an update to
Intelli-Dolphin as well as Small-Cruise and I've been sinking under a ton
of other things so havne't had a chance to sort them out. However I'll make
a Xmas push as well.

Tim