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)

org.eclipse.ui.commands?

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)

It might be possible to have a macro execute multiple commands as well. Given a list of commands or parameterized commands, just walk through them executing them through the handler service.

--Pwebster.ca.ibm.com 09:58, 5 October 2006 (EDT)

Undo

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)

Multi-page Editors and Supporting Views

Need to consider multi-page editors. For example a EditorPart that provides a graphical editor, a source code editor, and some number of previewers. As the user switches between these sub-editors the menu/toolbar contributions need to change visibility or enablement or behavior.

Supporting Views need to use Editor actions (like Undo or back). When a view is activated the associated Editor's menus/tools become disabled but sometimes the view wants those actions to remain active. For example, consider a graphical editor and associated Outline view. The editor has a "Select All Siblings" action (a variant of select all). The Outline view needs to support the same action. It is possible to set this up programmatically but this is difficult to maintain and extend.

Another consideration is providing a simple means for users to choose which actions appear on toolbars. When there are 20 – 40 actions that are candidate for toolbars there is a need to have fine grain control over which ones appear. This needs to be under the control of the program and the user. --bgil2005 2:03, 13 December 2006 (PDT)