Community
Participate
Working Groups
These comments, https://bugs.eclipse.org/bugs/show_bug.cgi?id=36968#c43 https://bugs.eclipse.org/bugs/show_bug.cgi?id=36968#c44 raised the issue of moving the handlers extension-point out of a UI plugin and ended with "If this is important for you, I would recommend filing a separate bug so that your comments do not get lost." I don't see a separate bug for it, so here it is. More than just the handlers extension-point, I'd like to see all of the MVC "model" stuff described in the link below moved to a "core" plugin: http://dev.eclipse.org/viewcvs/index.cgi/~checkout~/platform-ui-home/R3_1/contributions-proposal/requestForComments.html Clients that can't depend on UI, but can depend on the registry would benefit from this. The new plugin would contain the extension-points for "handlers", "commands" and "contexts" as well as the classes that process the registry and make the stuff available to clients (like ICommandService, CommandService, CommandPersistence, and likewise for handlers).
+1
I see you added "helpwanted". I'm not sure I should commit to doing a patch for this yet - I've looked at it some and I see a lot of tricky details. But maybe we should start by trying to define the scope of this work. Suppose we add a new plugin called "org.eclipse.core.commands.registry". Do you agree about moving (where "move" means "deprecate original") these three extension-points: org.eclipse.ui.commands -> org.eclipse.core.commands org.eclipse.ui.contexts -> org.eclipse.core.commands.contexts org.eclipse.ui.handlers -> org.eclipse.core.commands.handlers And a list of classes something like this: (API) IDisposable IServiceWithSources ICommandService IContextActivation IContextService IHandlerActivation IHandlerService (Internal) RegistryPersistence IRegistryConstants CommandPersistence ContextPersistence HandlerPersistence CommandService ContextService ContextActivation HandlerService HandlerProxy HandlerActivation I'm sure that's not exactly right though. One thing making me very nervous is I see ui dependencies in some of these classes. For example RegistryPersistence has a call to Display.getDefault().asyncExec(...). There are other things like that too. I think that the new plugin should only depend on org.eclipse.core.commands and org.eclipse.core.runtime. Maybe other "core" plugins but it should not depend on jface or any UI plugins.
I don't think it's practical to rename the extension points, but it is reasonable to move them. The other class could be moved. We could also move all of org.eclipse.ui.(internal.?)[commands|contexts|services], and then re-export the plug-in from org.eclipse.ui.workbench.
Moving Dougs bugs
*** Bug 158507 has been marked as a duplicate of this bug. ***
Just current bits of information. 1. The extension points can't go into org.eclipse.core.commands. It's a JFace dependency, and can't use the extension registry. Perhaps they can be moved closer to the org.eclipse.core.runtime plugin. 2. The split between core and workbench here is between Manager and Service. The pattern that seems to be used is managers contain the basic behaviour, and the service adds workbench specific behaviour. The theory is you can replicate the basic structure buy chaining the managers together, which is how the services build themselves up. PW
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant.
