Community
Participate
Working Groups
The "org.eclipse.ui.workbench" plugin contains elements that are useful and should be available to "simple" RCP applications. For exmple, the "Show View" dialog needed elements from the following packages: - org.eclipse.ui.dialogs (ShowViewDialog, FilteredTree, PatternFilter - org.eclipse.ui.internal.dialogs (ViewComparator, ViewContentProvider, ViewLabelProvider, ViewPatternFilter - org.eclipse.ui.progress (UIJob, WorkbenchJob) - org.eclipse.ui.internal.misc (StringMatcher) - org.eclipse.ui.plugin (AbstractUIPlugin)
> The "org.eclipse.ui.workbench" plugin contains elements that are useful and > should be available to "simple" RCP applications. I don't understand the motivation here. The org.eclipse.ui.workbench plugin was originally created by extracting the generic RCP elements out of org.eclipse.ui. The non-RCP parts were put in org.eclipse.ui.ide. What parts of org.eclipse.ui.workbench aren't interesting to RCP applications? Or, is this an e4 vs. compatibility split you are thinking of?
I was under impression that org.eclipse.ui.workbench won't be used by pure e4 applications. (For instance, our demos run without it.) From a quick look at the code, it seems that there are number of areas that have different e4 implementation (presentation, themes, parts, D&D, contexts, activities, editor and workbench support).
I see, so this is about extracting elements from org.eclipse.ui.workbench that won't have an equivalent in the e4 API. That makes sense, although it might be another year (4.1) before we have a really accurate picture of what that set looks like.
See related discussion in bug 318257. org.eclipse.e4.ui.workbench3 was originally created to start this process of separating legacy API from API that can be used in pure e4 applications.
I compared some classes from org.eclipse.e4.ui.workbench.swt.internal.copy with their "originals" in org.eclipse.ui.workbench and all of them had more or less big differences. So I think it's time to remove those copied classes. What about a new project named org.eclipse.ui.core or org.eclipse.core.ui or org.eclipse.core.workbench, which can be used by org.eclipse.ui.workbench (3.x) and org.eclipse.e4.ui.workbench? At least the classes mentioned in the description should go there. The existing API-classes in ui.workbench can extend the core classes (without changes) and marked as deprecated, to avoid breaking changes.
core is our name for non-ui stuff so core cannot be used as part of the plugin name for UI stuff. e4.ui or something is ok. +1 for the general idea.
(In reply to Lars Vogel from comment #6) > core is our name for non-ui stuff so core cannot be used as part of the > plugin name for UI stuff. > > e4.ui or something is ok. > > +1 for the general idea. That means that ui.workbench gets a dependency to e4.ui, just for clarification.
Anything in e4 who does not contain "swt" is today widget toolkit neutral and I'd like to keep this so => the name needs to contain "swt" somewhere
(In reply to Conrad Groth from comment #7) > (In reply to Lars Vogel from comment #6) > > core is our name for non-ui stuff so core cannot be used as part of the > > plugin name for UI stuff. > > > > e4.ui or something is ok. > > > > +1 for the general idea. > > That means that ui.workbench gets a dependency to e4.ui, just for > clarification. That is fine.
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. As such, we're closing this bug. If you have further information on the current state of the bug, please add it and reopen this bug. 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. -- The automated Eclipse Genie.
