Community
Participate
Working Groups
In my RCP app I have created a small set of prefs-pages, which are neatly displayed in the little "FilteredTree" to the left. But a user-request is to have that tree expanded by default on opening the Prefs-page; this is reasonable, as there are notvery many elements in the tree. As far as I can tell from the extension-point, the interface of FieldEditorPreferencePage, and the interface of IPreferencePageContainer, there is no way to do this. For example, the API to FilteredTree could have methods like the following, with some forwarding methods from PreferencePage to the implementation of IPreferencePageContainer, or the connection could be made in other ways: public void expandAll() { treeViewer.expandAll(); final ISelection sel = treeViewer.getSelection(); if (!sel.isEmpty()) { final IStructuredSelection iss = (IStructuredSelection) sel; treeViewer.reveal(iss.getFirstElement()); } } public void setExpandedElements(Object[] elements) { treeViewer.setExpandedElements(elements); }
This won't be possible for 3.2 as we are well past the API freeze. The FilteredTree class was not promoted to API until 3.2. Also note that the FilteredTree is not tied to IPreferencePageContainer at all, since it can be used in a general way in places other than just the preferences dialog, so adding API to that will not solve the problem. It would have to be added to FilteredTree.
Dani, what API do you need on FilteredTree to unblock bug 139798? Just what is suggested below?
Hi Karice, on a second thought we don't need it at all since we have access to the tree viewer (getViewer()) and our code already uses this API on the viewer directly. Blocking us from doing so is bug 158279.
The API needed is available via the tree widget itself, which is exposed via the viewer, which is exposed on the filtered tree class. The convention is not to provide convenience API when access to the viewer/widget itself is provided.
(In reply to comment #4) > The API needed is available via the tree widget itself, which is exposed via > the viewer, which is exposed on the filtered tree class. The convention is not > to provide convenience API when access to the viewer/widget itself is provided. > Perfectly reasonable convention, but how is it relevant here? There is no API on the *Preference Page* to control the filtered tree's expansion-state. Another missed opportunity.
Ok, so I didn't re-read the original description saying that you wanted a preference page to provide the API. Adding API to an interface is not feasible as it will break binary compatibility. However, it can be provided by making PreferenceDialog.getTreeViewer() public, rather than protected. Then, in your open preferences dialog action you can create the preference dialog, call expandAll() on the tree viewer, then open the dialog. e.g. PreferenceDialog dialog = PreferencesUtil.createPreferenceDialogOn(null, null, null, null); dialog.getTreeViewer().expandAll(); dialog.open(); Will this suit your needs? If so, re-open this bug.
Yes, thanks, that solution should work for me -- I'm in an RCP, so could create my own open-prefs action rather than using the action-factory item. (Not clear to me if this would help folks working on plug-ins for the JDT ...)
This functionality is probably most useful in an RCP setting anyway. Released in 3.3 for build > 20070131
