Talk:Platform UI Command Design
Commands, Handlers, and KeyBindings are mostly done. Now we need support to place command items in menus and toolbars.
--Pwebster.ca.ibm.com 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. --Ed.burnette.sas.com 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.
- --Pwebster.ca.ibm.com 13:21, 14 September 2006 (EDT)
Macros, scripting, etc.
There should be more info here about how this helps macros (scripting). --Ed.burnette.sas.com 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.
- --Pwebster.ca.ibm.com 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. --Ed.burnette.sas.com 11:33, 13 September 2006 (EDT)