Skip to main content

Notice: this Wiki will be going read only early in 2024 and edits will no longer be possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.

Jump to: navigation, search

Difference between revisions of "Talk:Platform UI Command Design"

(org.eclipse.ui.commands?)
(Multi-page Editors and Supporting Views)
 
(3 intermediate revisions by 2 users not shown)
Line 22: Line 22:
 
: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.
 
: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.
 
:--[[User:Pwebster.ca.ibm.com|Pwebster.ca.ibm.com]] 08:39, 26 September 2006 (EDT)
 
:--[[User:Pwebster.ca.ibm.com|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.
 +
::--[[User:Pwebster.ca.ibm.com|Pwebster.ca.ibm.com]] 09:58, 5 October 2006 (EDT)
  
 
== Undo ==
 
== Undo ==
Line 27: Line 30:
 
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.
 
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.
 
--[[User:Ed.burnette.sas.com|Ed.burnette.sas.com]] 11:33, 13 September 2006 (EDT)
 
--[[User:Ed.burnette.sas.com|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.
 +
:The MultiPageEditorPart implementation provides an appropriate editor action contributor that manages all of the actions for that editor.  Although with the new system you could activate different contexts with each inner editor, and tie the action visibility to that context.
 +
:--[[User:Pwebster.ca.ibm.com|Pwebster.ca.ibm.com]] 10:51, 18 December 2006 (EST)
 +
 +
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.
 +
:The new story is using commands+handlers to implement behaviour.  Your handler will be active in any parts the implement it (or all parts if you provide a default handler).
 +
:--[[User:Pwebster.ca.ibm.com|Pwebster.ca.ibm.com]] 10:51, 18 December 2006 (EST)
 +
 +
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.
 +
--[[User:bgil2005|bgil2005]] 2:03, 13 December 2006 (PDT)
 +
:It is in the plan to provide the override mechanism, which would allow RCP applications to pick remove specific menu items.  The application could then provide the user with very fine grained control.  The platform will probably also provide a dialog to do this on top of the override framework, but not in 3.3.
 +
:--[[User:Pwebster.ca.ibm.com|Pwebster.ca.ibm.com]] 10:51, 18 December 2006 (EST)

Latest revision as of 11:51, 18 December 2006

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.

The MultiPageEditorPart implementation provides an appropriate editor action contributor that manages all of the actions for that editor. Although with the new system you could activate different contexts with each inner editor, and tie the action visibility to that context.
--Pwebster.ca.ibm.com 10:51, 18 December 2006 (EST)

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.

The new story is using commands+handlers to implement behaviour. Your handler will be active in any parts the implement it (or all parts if you provide a default handler).
--Pwebster.ca.ibm.com 10:51, 18 December 2006 (EST)

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)

It is in the plan to provide the override mechanism, which would allow RCP applications to pick remove specific menu items. The application could then provide the user with very fine grained control. The platform will probably also provide a dialog to do this on top of the override framework, but not in 3.3.
--Pwebster.ca.ibm.com 10:51, 18 December 2006 (EST)

Back to the top