[platform-ui-dev] Parameterized Commands (was 'Key Binding Problem')

[Chris McLaren <Chris_McLaren@xxxxxxxxxx>]

> On March 8, 2004 04:19 pm, Randy Hudson wrote:
> > A) The user can define his own templates (Tools), and needs to
be able to
> > assign a keybinding for it.  But, commands currently must
be defined in
> > the plugin.xml file.  This is not possible.  The number
and IDs for the
> > commands are unknown at development time.  So we need programmatic
ways to
> > define new commands.
> 
> I believe the approach we were going to take was one of parameterized
> commands.  Chris can probably comment more.  Chris: perhaps
we should bump up 
> the priority on getting parameterized commands?


This belongs to one class of long-standing problems
I'd like to solve as part of a new API I've been working on for 'commands'.
You can walk this API starting at IWorkbench.getCommandSupport.

Many of the bugs in this class are phrased in terms
of key bindings, as in 'How come I can't assign a key binding to...'
- Open/close a particular view/perspective?
- Run a particular macro?
- Run a particular launch configuration

Key bindings are assigned to commands. I'd like this
assignment to be able to carry optional parameter(s). I'd like the command
definition to be able to provide information on its accepted parameter
types such that the key bindings dialog can provide valid parameter choices
and/or validate a user's typed in parameter.

One of the goals of the commands work is to unify
the mechanisms of 'handling' command execution. (global actions, action
sets, view/editor actions, object contributions, etc..) We are introducting
the notion of a command 'handler' for 3.0. Think of a handler as the 'run()'
part of a jface action, without any mention of jface actions. The eventual
goal is to phase out 'actions' altogether, but that's the subject of another
email (please let me have until after M8 to answer that email.. :)

Handlers can receive parameters as part of their 'execute(..)'
method. With this we would have an end-to-end solution for this dynamic
command problem.

Some examples (all of which are currently open feature
requests):

1. Workbench could add a command called 'Open View'.
Its command definition would specify a parameter class which would enumerate
the set of views in the system. The key binding dialog would allow one
to assign a key sequence to this command, querying this parameter class
to provide the proper UI to make a selection from the parameter list (like
a combo box of the view names..). With the help of the parameter class,
the view's name would be stored as the view's id. Workbench would create
a handler for this command which accepts a view id as a parameter. When
the key sequence is pressed, WorkbenchKeyboard executes the command with
the parameter in the key binding. The CommandManager passes this parameter
to the handler, et voila. The handler might allow no parameters - perhaps
it would open a popup of the available views?

2. A third party plugin could contribute a macro system
to eclipse which could allow the user to create macros of commands to execute
in sequence. I imaging it could a provide a macro construction dialog,
using the commands API to query the set of available commands, allowing
the user to create, save, delete, etc. macros by name. Not only could the
individual commands in a macro make use of parameters, but the macro system
itself could define a single command called 'Run Macro' which accepted
a 'macro name' as a parameter. The macro system could provide a handler
which looks up macros by name, and executes the commands in sequence. The
handler might allow no parameters - perhaps it would open a popup of the
available macros?

3. Debug could add a command for 'Run Launch Configuration'
which took a launch configuration id as a parameter. I won't duplicate
the description of how to implement this - its the same as above)

Though I said previously these problems are usually
phrased in terms of key bindings, this work isn't just for key bindings.
This commands API paves the way (post 3.0) for explicitly defined menus
and toolbars in terms of commands (as opposed to the current implicit,
and in my opinion, backwards mechanism provided by actions). Explicitly
defined menus and toolbars not only means user menu/toolbar customization
in the future, it means debug, for instance, could add dynamic menu items
for it's launch configurations (making use of parameters) which go through
the same command->handler execution path. If a user happens to define
a key binding to run one of these launch configurations, the key binding
would automatically show up on the dynamic menu item, as the parameters
would match.

As for 'bumping up priority', if you mean slow the
rotation of the earth to make more hours in a day, I'm all for that. Otherwise
'new look' has the priority right now. I personally think, however, that
this is one of a number of very powerful features the command system offers
worth completing for 3.0. Hopefully, we will just finish all tasks in platform-ui
for 3.0 so nothing has to fall off the boat.

Chris