Community
Participate
Working Groups
org.eclipse.ui.* has some useful bits that are now off-limits for pure Eclipse4 RCP apps. If the org.eclipse.ui.* bundles cannot be adapted to be included in such apps without the compatibility layer, perhaps we could consider introducing a new bundle, say org.eclipse.e4.ui.rcp or org.eclipse.e4.ui.rcp.jface, to hold equivalents? Useful bits that I've come across: * Useful dialogs, like the enhanced preferences dialog (FilteredPreferenceDialog, though it's internal) * ScopedPreferenceStore * SelectAllHandler Other areas that would be nice to have work, perhaps by reducing their dependencies solely to JFace: * the simplfied p2 UI dialogs * the Equinox Security dialogs * UI Forms
Brian, this (at least part of it) is already in the works for Eclipse 4.2. We were already looking into moving a variety of the more useful views over but we hadn't considered these bits... The views we can move over using Tom's 'forward compatibility layer' (after removing dependencies) because we 'own' them but I'm less sure whether we own everything on this list (such as UI Forms) so it'd be a selling job to convince the component devs to do the work (we will of course help where we can, keeping Eclipse 4 RCP apps as tight as possible is a really good thing IMO).
(In reply to comment #0) > Other areas that would be nice to have work, perhaps by reducing their > dependencies solely to JFace: > > * the simplfied p2 UI dialogs > * the Equinox Security dialogs > * UI Forms Forms has a dependency on the workbench because there are those form editors. The other pieces in its repertoire does not actually need the workbench though.
I wonder if it's worth creating split bundles as happened with the breakup of org.eclipse.core.runtime into different pieces. I'd guess that 99% of our consumers were using 'Require-Bunde: org.eclipse.ui'.
*** Bug 370046 has been marked as a duplicate of this bug. ***
Also see bug 369657.
Just for completeness I think the following dialogs are worth saving: ElementListSelectionDialog ListDialog ElementTreeSelectionDialog CheckTreeSelectionDialog Looks to me like the whole org.eclipse.ui.dialogs package could be moved to a new plug-in.
I would like to port a few dialogs. Which plug-in ID should I use?org.eclipse.ui.dialogs sounds good but I guess this would overlap with org.eclipse.ui.*
(In reply to comment #7) > I would like to port a few dialogs. Which plug-in ID should I > use?org.eclipse.ui.dialogs sounds good but I guess this would overlap with > org.eclipse.ui.* Which dialogs would you like to port? Just the ones mentioned in comment #6 ? What are their purpose? And by that I mean, what unit of functionality do they expose (and so we should group them together)? What would keep them from being moved into org.eclipse.jface.dialogs? PW
@Paul, I ported ListSelectionDialog and SelectionDialog because there was a question on the Eclipse Forums for them: http://www.eclipse.org/forums/index.php/t/369279/ I think org.eclipse.jface.dialogs would be a good place for them. If you desire I can create a patch from them.
(In reply to comment #9) > @Paul, I ported ListSelectionDialog and SelectionDialog because there was a > question on the Eclipse Forums for them: > http://www.eclipse.org/forums/index.php/t/369279/ > > I think org.eclipse.jface.dialogs would be a good place for them. If you > desire I can create a patch from them. Don't they need workspace stuff like Help, ...?
If they don't require anything except SWT then JFace would be the appropriate place. But if we expect to use DI etc then perhaps we should make 'org.eclipse.e4.dialogs' ??
ListSelectionDialog sets an ID for the help system but it looks to me that consumer anyhow override this value. For example: ListSelectionDialog: PlatformUI.getWorkbench().getHelpSystem().setHelp(shell, IWorkbenchHelpContextIds.LIST_SELECTION_DIALOG); FeatureSelectionDialog: PlatformUI.getWorkbench().getHelpSystem().setHelp(newShell, helpContextId); My assumption would be that we can safely remove them in ListSelectionDialog without heavily affecting consumers.
(In reply to comment #12) > My assumption would be that we can safely remove them in ListSelectionDialog > without heavily affecting consumers. We would probably want to allow ui.workbench functionality to be pluggable into the refactored dialogs, regardless of if they end up in jface or e4.ui.dialogs. PW
@Paul: I will check if a user in ui.workbench does not reset the help ID.
I don't find a lot of usage for ListSelectionDialog in the platform. I checked ProjectSourceContainerDialog and CategoryFilterSelectionDialog and they reset the help ID. I think migrating this dialog to JFace is be save and the platform could use this dialog. Patch attached, I introduced the package *.listdialogs as *.dialogs seemed already crowed. Please let me know if I should change that.
Created attachment 219910 [details] Patch to add ListSelectionDialog to JFace
Just to muddy the waters a bit...;-) While looking into this you may want to see whether it makes sense to port the view over to using data binding. This at least gives us a shot at having the view itself run in non-SWT environments.
@Eric: I like that the report go into the JFace plug-in and JFace should not depend on Databinding.
OK, time to start working on this one. I'm taking a first cut at 'porting' the LogView. So far it's not so bad but there some issues that are already surfacing: Many (most?) of our standard views are *very* old and us JFace Actions. Right now I'm looking at various options since the low-level model code is even more verbose than what it's replacing. We will also need to find a strategy for hosting common helper classes like IMemento / XMLMemento. After going over this with Paul we're gonna start by moving the classes into a different bundle and leaving stubs that 'extend' the existing ones for backwards compatibility.
@Eric, sounds great. Looking forward to the first port.
*** Bug 351363 has been marked as a duplicate of this bug. ***
*** Bug 392715 has been marked as a duplicate of this bug. ***
Just to report back...the attempt to port the Log View was an abject failure...there are just too many dangling 3.x bits to do this easily (I spent a full week on the simplest view I could find).
But the progress view is coming along nicely. It just needs some e4 consumer feedback. Bug 429505
(In reply to Eric Moffatt from comment #11) > If they don't require anything except SWT then JFace would be the > appropriate place. But if we expect to use DI etc then perhaps we should > make 'org.eclipse.e4.dialogs' ?? org.eclipse.e4.dialogs sounds good to me but I think we should also add ui to it, e.g. org.eclipse.e4.ui.dialogs to be consistent with the other e4.ui plug-in namings. Created Bug 440367 for this.
(In reply to Thomas Schindl from comment #10) > Don't they need workspace stuff like Help, ...? For the help we should work on a e4 help service. I suggest one improvement in Bug 445600.
With http://git.eclipse.org/c/platform/eclipse.platform.ui.git/commit/?id=dbc9a53ba623739a3663582936502e295d5ad293 we have now a new plug-in to migrate org.eclipse.ui.dialogs components (which can not go to JFace because of their dependencies). Also for the Help we have a strategy with Bug 445600. I mark this general bug therefore as fixed and suggest we open / work on more specific bugs for additional migration work.
.
