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?)
Line 7: Line 7:
 
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.
 
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.
 
--[[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)
 +
 +
: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.
 +
:--[[User:Pwebster.ca.ibm.com|Pwebster.ca.ibm.com]] 13:21, 14 September 2006 (EDT)
  
 
== Macros, scripting, etc. ==
 
== Macros, scripting, etc. ==

Revision as of 13:21, 14 September 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)

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)

Back to the top