Community
Participate
Working Groups
From the jdt-ui mailing list: (Joseph Fifield <jfifield@programmerplanet.org>) > I would also love to see things like the "select source folder", "select > package", and "select class" dialogs exposed for reuse (they seem to be > internal now). Are currently any plans for this? The JDT-UI has interal selection dialogs like TreeSelection, ListSelection, TwoPageSelection that offer good value. They are completly JDT independend and could be moved and exposed the desktop.
It does not make sense to expose non JDT UI specific capabilities as API in the JDT plugin. Are these the only classes that you would like to see moved to the UI plugin?
*** Bug 10145 has been marked as a duplicate of this bug. ***
Yes, there are other components that would be of value. The dialogs are the ones that are the easiest to move, as, in my opinion, the APIs are cleaned up and the code is in good condition. Other components would be a checked/ordered selection list: Up/down, select/deselect all and user definable buttons. In JDT UI this is the class ListDialogFieled and CheckedListDialog. The classes are used in many places in JDT; preference/property pages, wizards, dialogs. However, I think the API is not very standard. These are the dialog classes ready to be moved to the desktop: ElementListSelectionDialog.java MultiElementListSelectionDialog.java TwoPaneElementSelector.java ElementTreeSelectionDialog.java CheckedTreeSelectionDialog.java SelectionStatusDialog.java AbstractElementListSelectionDialog.java FilteredList.java
*** Bug 12599 has been marked as a duplicate of this bug. ***
Did not make it for M5. Will do early M6.
Encountered the following extra ties to JDT: - StatusLineDialog refers to MessageLine and StatusInfo - StatusInfo is a non-standard implementation of IStatus - it hardcodes JDT's plugin id - changed to use Core's Status instead - MessageLine cannot be pushed down as-is: - it's a subclass of CLabel, and org.eclipse.ui does not define new widgets (this is an SWT Custom responsibility) - could just make this a private class though - it refers to JavaPluginImages for error, warning and info images - org.eclipse.ui has equivalents for the task list though - it has a hardcoded colour (ERROR_BACKGROUND_RGB) which should be avoided for accessibility reasons - could probably find a similar system colour in SWT though (e.g. SWT.COLOR_DARK_GRAY or SWT.COLOR_WIDGET_DARK_SHADOW) - I don't believe dispose() is called if a parent widget is disposed, so this may leak a Color - probably needs to hook a dispose listener on itself instead - pushing down as internal for now - CheckedTreeSelectionDialog refers to ContainerCheckedTreeViewer - pushing ContainerCheckedTreeViewer down to JFace - AbstractElementListSelectionDialog and CheckedTreeSelectionDialog refer to ISelectionValidator, which is incompatible with the one in org.eclipse.ui.dialogs - renamed to ISelectionStatusValidator - would be more generic if it took an ISelection? - FilteredList refers to StringMatcher in org.eclipse.jdt.internal.ui.util.StringMatcher - we don't want another copy of StringMatcher in the Workbench - made one anyway for now, in org.eclipse.ui.internal.misc - FilteredList refers to TwoArrayQuickSorter - made TwoArrayQuickSorter have package visibility in org.eclipse.ui.dialogs Other issues: - FilteredList: - LabelComparator does not use a Collator, so is not locale sensitive - MultiElementListSelectionDialog seems too specialized to JDT - is only used by Organize Imports - TwoPaneElementSelector seems too specialized to JDT - is used by TypeSelectionDialog, MainTypeSelectionDialog, and TestSelectionDialog - TwoArrayQuickSorter - StringComparator does not use Collator, so is not locale sensitive
More issues: AbstractElementListSelectionDialog has protected field fFilteredList. Should be private with protected getter and setter instead. AbstractElementListSelectionDialog.createFilteredList both returns the list and assigns it to the field. Should do one or the other, but not both. TypeSelectionDialog should refer to either the result of super, or the field, but not both. FilteredList constructor does not follow SWT style. Should just take parent and style bits, and have setters for the rest. This feels more like a specialized table viewer rather than a new kind of widget.
Agree on all issues. - Usage of StatusInfo can be replaced with Status(..) - Ok for me to not move MultiElementListSelectionDialog - TwoPaneElementSelector is valuable, I would move it. Note that ContainerCheckedTreeViewer needs a review. Some more methods have to be overwritten to make sure that programtically setting the checked/gray state does not lead to invalid states.
OK, I've removed MultiElementListSelectionDialog.
Moved ContainerCheckedTreeViewer to org.eclipse.ui.internal.dialogs until API is reviewed.
Closing.
