Skip to main content
Jump to: navigation, search

Talk:Platform UI Command Design

Revision as of 08:40, 26 September 2006 by (Talk | contribs) (org.eclipse.ui.commands?)

Commands, Handlers, and KeyBindings are mostly done. Now we need support to place command items in menus and toolbars. 08:35, 17 August 2006 (EDT)


Shouldn't the commands extension point be in org.eclipse.core? It should be possible to drive behavior in a headless application - there would just be no menus or icons or key bindings. 11:33, 13 September 2006 (EDT)

It hasn't been considered, at least not so far. Reading the commands, parameters, and states in org.eclipse.core.commands would in theory be possible. It's also possible to read the contexts in org.eclipse.core.commands as well.
The mechanisms that track evaluation context source changes, that evaluate handlers to see if they're active or not, and that can correctly execute a command and its handler is more firmly tied to org.eclipse.ui.workbench.
It's still a possibility that the commands could be read by org.eclipse.core.commands, but hooking up/providing more menu flexibility is the top priority for 3.3. 13:21, 14 September 2006 (EDT)

Macros, scripting, etc.

There should be more info here about how this helps macros (scripting). 11:33, 13 September 2006 (EDT)

I think that the platform can help macros by going through the supplied commands and adding (what will probably be optional) parameters. Then if the command is called with parameters perhaps a lot of them won't need to open dialogs for user input. 08:39, 26 September 2006 (EDT)


Special thought should be given to how this fits in with "undo" functionality. It seems the simplest thing would be to require each command to not only specify a class to "do" something, but also to "undo" it. I know there's a whole undo framework and IUndoableOperation, etc., but it all seems like overkill to me for such basic functionality. 11:33, 13 September 2006 (EDT)

Back to the top