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

[Stefan Xenos <Stefan_Xenos@xxxxxxxxxx>]

Chris,

I'm interested in how parameterized
commands get bound. It sounds as though the plugin-provided parameter class
can enumerate the possible values for the command and the framework will
always display these values in a list. 

The command author may want to customize
the UI that the user sees when they first bind the command. Maybe a list
isn't the best UI for every command -- I imagine that some commands might
take a filename or an equation as a parameter (imagine a command that launches
a user-defined external program). Perhaps we could consider a model more
like the JDT's classpath variables. Whoever provides the parameterized
command also provides a wizard page that allows the user to bind or edit
that parameter... which allows them to display whatever UI makes the most
sense for the command.

  - Stefan

Chris McLaren/Ottawa/IBM@IBMCA Sent by: platform-ui-dev-admin@xxxxxxxxxxx 03/09/2004 11:22 AM Please respond to platform-ui-dev

To:        platform-ui-dev@xxxxxxxxxxx         cc:                 Subject:        [platform-ui-dev] Parameterized Commands (was 'Key Binding 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)