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

[Randy Hudson <hudsonr@xxxxxxxxxx>]

It still seems like we need the ability
to define command definitions programatically.  Clients such as the
Visual Editor Project do not know anything in their palette ahead of time,
and could not define the necessary commands in their plugin.xml.  I'm
not sure that parameterized commands would solve the problem.  Basically,
we would have to call the command a "palette button", and the
parameter would have to be flexible enough to define anything at all. The
list of choices would not be fixed, but could be based on the JavaBeans
which had been added to the palette by the user.  Palettes may even
be specific to Java Projects, which is another reason why we need to edit
the keybindings in our palette's dialog and not the (global) preference
page.  Maybe we should just use Display.addFilter().
======================
The new API is prone to making mistakes.
 When a client creates a handlersubmission specific to a WorkbenchSite,
this seems similar to the old way of registering an Action with
the Site's keybinding service.  But there is a difference.  For
the 2.1 keybinding service, it was "set it, and forget it".  When
the part was disposed, the registered actions were released.  I realize
that the current API means there is a single entry point for hooking up
all kinds of handlers (site-specific, window-specific, workbench-global).
 So doing it the old way would mean there would have to be entry points
in 3 different places (4 with IPageSite).  More work for you, less
for clients.
======================
There are some issues in the latest
integration build.
-If you enable a context, but do not
register any handlers, the keybindings get consumed by the workbench.
-A HandlerSubmission specifying an IPageSite
doesn't work.
-registering actions through the keybinding
service still causes memory leaks.  CU editor for example.

Randy Hudson