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

[Chris McLaren <Chris_McLaren@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(). 

Right now, the parameter is any Object, and we haven't
even defined the parameter class yet. Therefore, I think the opportunity
exists to make this flexible enough for you. How is a dynamic set of palette
options different from any of the other use cases? (run launch configurations,
run macros, open views)

Not only do I think parameterized commands is there
right thing for your use case, there is still the possiblity we can allow
clients to define a command programmatically, but this is currently not
exposed in the api. We just haven't seen any use cases yet which aren't
best covered by parameterized commands. (in our humble opinion :)

> 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. 

IKeyBindingService always had an unregisterAction
method, but no one used it properly, instead relying on 'set and forget'
- something the API doesn't even guarantee. We will be asking people to
remove their handlers when their part is disposed. 

> 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. 

I'm not clear on your example, but I will take a guess.
We decided the commands could win the right to keybindings provided the
scope, configuration, platform, etc. was correct only, whether or not those
commands had handlers. From the keybinding side, it thinks of a command
without handlers the same as 'disabled'. If you have a strong case why
this should not be the case, we can consider changing this behavior.

> -A HandlerSubmission specifying an IPageSite
doesn't work. 
> -registering actions through the keybinding service still causes 
> memory leaks.  CU editor for example. 

We will check into these, thanks.