Community
Participate
Working Groups
The tabbed properties view displays tabs and sections based on PropertyTab and PropertySection extensions. These extensions are read from plugin.xml and stored in a internal registry. Clients would like to override the tabs and sections in the tabbed property registry with a new set based on a selection.
+1 for needing it sooner rather than later. The WTP DTD editor makes use of the tabbed properties page and uses a different set of tabs based on the selected objects (the tabs for an element declaration being completely different from the one shown for a comment).
Note that you can use a filter on the section to enable a section or not based on the objects in the selection. The filter can check if the object is a element declaration or comment.
Anthony, if I'm reading this right, your filter selection might work fine for the case where there's 2 or 3 or 4 types of things to filter out (all known in advance, by same plugin, I guess), but I believe there are clients of the "old" tabbed properties view that have dozens of such "categories", so, seems a little burdensome to do it by the "filter out" approach. (as well as potential impact to performance, if changes plugin activation behavior, for example, such as if many plugins have to be loaded to "rule out" all possibilities). I'm not expert in this "previous use of UI properties" ... so, I'm half guessing, but just thought I'd keep the discussion going.
*** Bug 156978 has been marked as a duplicate of this bug. ***
To confirm the requirements of this request: Currently, when a selection change event is received, the tabbed properties view tabs and sections for the contributor are displayed based on extensions read from plugin.xml. The clients I am familiar with do not want to use extensions or plugin.xml, they would like the configuration created entirely from code. Please confirm if there are any additional requirements out there.
I suppose it's needless to say, however: it would be needed that as a model that lies behind the tabbed properties, arbitrary objects could be used and content and labels provided through standard provider interfaces. So, for example, there could be model objects like TabbedProperties 1->n Tab 1->n Section and they could be used through content providers to build the properties page.
We were unable to get available resources to work on this for 3.3. Now that 3.3 M6 and API freeze has past, we are going to have to look at Eclipse 3.4. I am going to add this to my list and attempt to deliver for 3.4 M1 which will be September 2007.
Hi all, as suggested by Ed Merks I write you to ask your opinion in order to implement this new feature. I should devote some (limited) time to develop a solution that copes with the current limitation, thus if you have already in mind the design changes needed, I could try to prototype it. In my use case, the selected item is a resource associated to a variable number of metadata. I can retrieve the schema and represent the metadata as a list of properties even if I don't know the schema in advance. Hence the dynamic aspect to provide the metadata grouped by tabs (schemas) is what effectively I need. I don't need a sophisticated approach so far, I mean no editing or custom sections capability. So my first thought was of extending the PropertyDescriptor class to add a set/getTab() method (similar to the setCategory one) and to modify the UI layout of the PropertyView to handle tabbed tables. I haven't in mind how complex is the design behind the Tabbed properties and, being pragmatical, I guess my approach would be more effective avoiding to achieve backward compatibility, but if you give me some hint I could try (i'm not so expert) to work on it following your design/development requirements.
I can request through the platform PMC premission to deliver the requested non breaking API additions in 3.3 M7 if we think there is significant value add for this feature. There are a number of new CCs on this bug. Anyone like to add their vote to this getting into Eclipse 3.3 M7?
(In reply to comment #9) > There are a number of new CCs on this bug. Anyone like to add their vote to > this getting into Eclipse 3.3 M7? I wholeheartedly support this motion.
Yes, I would love that! :-)
yep, +1
That would be great!!! +1
+1
What would these non-breaking API additions be?
(In reply to comment #15) > What would these non-breaking API additions be? Changes to provide dynamic tab and section support :-) I will update when I have made progress.
I spent last week looking at this engancement request. Objective: The tabbed properties view displays tabs and sections based on propertyTab and propertySection extensions. These extensions are read from plugin.xml and stored in a internal registry. Clients would like to override the tabs and sections in the tabbed property registry with a new set based on a selection. Clients need a way to provide TabDescriptors and SectionDescriptors currently defined in extension points. This would require a change to the propertyContributor extensions to allow for a new optional TabDescriptorProvider and SectionDescriptorProvider. change: Add optional tabDescriptorProvider and sectionDescriptorProvider to the propertyContributor extension schema Now that we have TabDescriptorProvider and SectionDescriptorProvider, we need to open up the API so that clients can provide TabDescriptors and SectionDescriptors. change: Add new public interfaces ITabDescriptorProvider and ITabDescriptor , there already exists a public ISectionDescriptorProvider and ISectionDescriptor Add public AbstractTabDescriptor and AbstractSectionDescriptor as default implementations of TabDescriptors and SectionDescriptors Change the internal TabDescriptor and SectionDescriptor now extend these abstract classes. Move private Tab to public final class TabContents describing the tab contents in terms of sections. AbstractTabDescriptor makes use of TabContents Change public TabbedPropertySheetPage to use the above classes and interfaces. There exists an issue that the public API ITabSelectionListener has a method public void tabSelected(TabDescriptor tabDescriptor); This need to be replaced with public void tabSelected(ITabDescriptor tabDescriptor); change: Add new public interface ITabSelectionListener2 that supports ITabDescriptor. I need to investigate futher: 1) I just had one propertyContributor in the prototype, clients have the need for more than one contributor of tabs and sections, which is currently accomplished by multiple propertyTab and propertySection extensions. I need to make sure we can have multiple propertyContributor providing multiple TabDescriptorProvider and SectionDescriptorProvider. 2) Clients wants to remove tabs and sections from other contributors (override tabs and sections). I have not started on an implementation for this yet. Given the work outstanding and the number of changes above, we do not have time in M7 to stuff this in. Leaving on 3.4
Created attachment 69495 [details] patch providing dynamic tab support As I'm also very interested in support for dynamic tabs, I had a look at the steps described in comment #17. I don't provide another extension point for tab descriptor providers though, but query the selection dynamically for an ITabDescriptorProvider (via instanceof and getAdapter(), similar to how IPropertySource works in the "plain" properties page). Maybe both approaches could be combined, but I don't see an immediate advantage of an extra extension point. Here's a description of the changes I made to org.eclipse.ui.views.properties.tabbed and org.eclipse.ui.tests.views.properties.tabbed. Note that I used the R3_2_maintenance branch for now, but I'd happily switch over to 3.4 for further work. SectionDescriptor - introduce and make use of superclass AbstractSectionDescriptor - move reusable methods and fields AbstractSectionDescriptor TabbedPropertyRegistry - use ITabDescriptor or AbstractTabDescriptor where applicable - move sorting of descriptors to new class TabDescriptorProviderManager (?) - implement ITabDescriptorProvider TabbedPropertyRegistryClassSectionFilter - make constructor and appliesToSelection() public (were protected) so that they are accessible to AbstractTabDescriptor (not in internal package) TabDescriptor - introduce and make use of superclass AbstractTabDescriptor - move reusable methods and fields AbstractTabDescriptor - make setSectionDescriptors(List) public (so that TabbedPropertyRegistry can access it) TabDescriptorProviderManager - introduced to handle both extension-point based descriptors and dynamic ones - queries the selection for ITabDescriptorProviders, e.g. via adapters - provides sorting of tab descriptors (moved here from TabbedPropertyRegistry) TabListContentProvider - now simply returns cached elements from TabbedPropertySheetPage (necessary because TabDescriptorProviderManager may answer different tab descriptors every time) AbstractSectionDescriptor - moved as much as possible from SectionDescriptor to AbstractSectionDescriptor - Note that getInputTypes(), appliesTo() and setTypeMapper() seem to be applicable to SectionDescriptor only, but are needed in order to satisfy ISectionDescriptor AbstractTabDescriptor - moved as much as possible from TabDescriptor to AbstractTabDescriptor ITabDescriptor - extracted from (Abstract)TabDescriptor - TODO: why getText() and getLabel()? ITabDescriptorProvider - new interface to be implemented by clients to dynamically provide ITabDescriptors - ITabDescriptor[] getTabDescriptors(IWorkbenchPart currentPart, ISelection currentSelection); ITabSelectionListener - deprecated in favor of ITabSelectionListener2 (using ITabDescriptor instead of TabDescriptor) ITabSelectionListener2 - new interface using ITabDescriptor instead of TabDescriptor - deprecates ITabSelectionListener (both are still supported though) TabbedPropertySheetPage - use TabContents instead of Tab and I*Descriptor interfaces where possible - cache calculated currentTabs in setInput() so that TabListContentProvider can access them via getCurrentTabs() - support both ITabSelectionListener and ITabSelectionListener2 - use TabDescriptorProviderManager to fetch ITabDescriptors - provide hook-method for subclasses protected TabContents createTab(ITabDescriptor tabDescriptor) - provide hook-method for subclasses protected ITabDescriptor[] getTabDescriptorsForSelection(IWorkbenchPart, ISelection) - remove parameters from private getLastTabSelection(IWorkbenchPart, ISelection), use cached currentTabs instead of querying registry - initContributor() -- remove previous registry instance from TabDescriptorProviderManager and add new one TabContents - renamed Tab to TabContents as suggested Some further comments: I think that the enabling and filtering in ISectionDescriptor actually only applies to the plugin.xml-based contributions and should therefore only be in SectionDescriptor, but not the interface nor AbstractSectionDescriptor. Dynamic contribtions will want to handle this themselves, I suppose. As the methods already exist in the released ISectionDescriptor, they cannot be removed, though. There are some plain collections used in the API (e.g. List), should those be converted to arrays? PS: sorry for those @version tags, they are generated automatically here
Thanks Carson, I will check this patch out. Early appologies that given this feature is scheduled for 3.4 M1 I will not get to the review until July. I should have attached my patch, but dynamic tabs did depend on my TabDescriptorProvider so this could provide another extensibility option.
No problem. I'll keep working on the patch and post updates here. I already have two small improvements: - let TabDescriptorProviderManager (previously TabbedPropertyRegistry) sort the tabs by their label as a last resort - add a protected factory method AdvancedPropertySheetSection.createPropertySheetPage() so that subclasses have the possibility to provide their own, e.g. to set a custom sorter I'm interested to hear about your other extensibility option. Thanks, Carsten
(In reply to comment #20) >I already have two small improvements: > - let TabDescriptorProviderManager (previously TabbedPropertyRegistry) sort the > tabs by their label as a last resort > - add a protected factory method > AdvancedPropertySheetSection.createPropertySheetPage() so that subclasses have > the possibility to provide their own, e.g. to set a custom sorter Both of these are invalid as the framework already has explict sorting as specified in the schema documentation (see categories and after section/after tab).
(In reply to comment #21) > Both of these are invalid as the framework already has explict sorting as > specified in the schema documentation (see categories and after section/after > tab). Yes, but the alphabetical sorting is only applied as a last resort, among those tabs in the same category and where no afterTab is set. And the factory method is only introduced into the AdvancedPropertySection, which embeds the plain old tree-based PropertySheetPage, for which no other sorting mechanism is available, AFAICS.
Created attachment 70363 [details] patch providing dynamic tab support Here's a new version of the patch. It contains all the changes as listed in comment #18 and additionally the following (listing those in comment #20 again). BTW, now I understood your idea of the propertyContributor extension point additions (ITabDescriptorProvider and ISectionDescriptorProvider) -- the adapter-facility only provides one single adapter. I updated the extension point as well, hopefully in a similar way as you did. AdvancedPropertySection - add a protected factory method createPropertySheetPage() so that subclasses have the possibility to provide their own PropertySheetPage, e.g. to set a custom sorter - make field tabbedPropertySheetPage protected (from private) so that AdvancedPropertySheetPage can use it AdvancedPropertySheetPage - register and unregister action contributions in the tabbedPropertySheetPage (e.g. "Show Advanced Properties"). Also makes the description hint work again (IPropertyDescriptor.getDescription() shown in the status line). schema/propertyContributor.exsd: - extend propertyContributor extension point for ITabDescriptorProviders as the adapter-facility only provides *one* single adapter per adapter-class (IPropertySource), that is, only one provider - extend propertyContributor extension point for ISectionDescriptorProviders TabbedPropertyRegistry - let registry read, instantiate and manage ITabDescriptorProvider and ISectionDescriptor extensions TabbedPropertyMessage - add new message (logged when ITabDescriptorProviders throw an exception) TabDescriptorProviderManager - sort the tabs by their label as a last resort (tabs in the same category and without afterTab being set)
Created attachment 73601 [details] Patch for Dynamic Tab and Section Support Patch for Dynamic Tab and Section Support. The patch also includes two examples in the tests plug-in (for JUnit tests). Note that the binary icons in the patch do not seem to work (The Eclipse create patch warns you that you cannot create a patch for binary changes).
Created attachment 73602 [details] Text Test View The first dynamic tab and section example is the Text Test View. Enter text and then select. Each word in the selection dynamically creates a tab and section for the word.
Created attachment 73603 [details] Dynamic Tests View Screenshot of the second example. A view to test dynamic contributions to the tabbed properties view. The view has three modes of providing tabs and sections to the tabbed properties view: use static contributions from plugin.xml, use dynamic section contributions from code, or use dynamic tab (and section) contributions from code.
(In reply to comment #24) Thanks for posting that patch, Anthony. I've applied it and only needed to adjust my code a bit to make it work. Very nice! The few issues I noticed so far are mostly about AdvancedPropertySection: - it's missing the connection to toolbar, statusbar, etc., so you ironically you can't edit "Advanced" properties, for example. - I'm missing a hook method AdvancedPropertySection.createPropertySheetPage() as mentioned in comment #20 - the page always has a horizontal scrollbar, at least on Linux GTK. I'm unable to resize the columns of the tree, so I can't even make that scrollbar go away, manually. You can see this with your Dynamic Tests View when selecting an entry and showing the "Advanced" tab. Finally, I'm missing a hook method TabbedPropertySheetPage.createTab(ITabDescriptor) as mentioned in comment #18. I'd be happy if you would consider these issues. Thanks, Carsten
(In reply to comment #27) > (In reply to comment #24) > Thanks for posting that patch, Anthony. > I've applied it and only needed to adjust my code a bit to make it work. Very > nice! Thanks for the review. I will check out your issues over the new few weeks. I have a vacation week in July. so don't worry if I take a bit.
(In reply to comment #27) > - the page always has a horizontal scrollbar, at least on Linux GTK. I'm unable > to resize the columns of the tree, so I can't even make that scrollbar go away, > manually. You can see this with your Dynamic Tests View when selecting an entry > and showing the "Advanced" tab. I have confirmed this issue exists in the original framework before applying the patch. This may be a duplicate of Bug 140314 .
(In reply to comment #27) > The few issues I noticed so far are mostly about AdvancedPropertySection: > - it's missing the connection to toolbar, statusbar, etc., so you ironically > you can't edit "Advanced" properties, for example. > - I'm missing a hook method AdvancedPropertySection.createPropertySheetPage() > as mentioned in comment #20 Raised Bug 198402 AdvancedPropertySection extensibility support, since this is separate from this dynamic tab and section support. (I put this new one on 3.4 M1 since you have provided a patch here).
Last comment to Carsten's comments :-) (In reply to comment #27) > Finally, I'm missing a hook method > TabbedPropertySheetPage.createTab(ITabDescriptor) as mentioned in comment #18. Since my examples are all selection based, I am wondering how to test this new proposed API. Do you have a use case on how this would work? Who calls this and when?
(In reply to comment #31) Hi Anthony, hope you had a good vacation :-) > (In reply to comment #27) > > Finally, I'm missing a hook method > > TabbedPropertySheetPage.createTab(ITabDescriptor) as mentioned in comment #18. > > Since my examples are all selection based, I am wondering how to test this new > proposed API. Do you have a use case on how this would work? Who calls this and > when? OK, let me elaborate on this: "my" version of TabbedPropertySheetPage.updateTabs(ITabDescriptor[]) calls this method instead of directly creating the tabs itself: protected void updateTabs(ITabDescriptor[] descriptors) { Map newTabs = new HashMap(descriptors.length * 2); boolean disposingCurrentTab = (currentTab != null); for (int i = 0; i < descriptors.length; i++) { TabContents tab = (TabContents) descriptorToTab.remove(descriptors[i]); if (tab != null && tab.controlsHaveBeenCreated()) { if (tab == currentTab) { disposingCurrentTab = false; } } else { tab = createTab(descriptors[i]); } [...] That way, a subclass can override createTab() and do something with the created tab, for example. In our case, we need to set the root entry of the PropertySheetPage. (PropertySheetPage.setRootEntry()). To do that, we need to intercept the TabContents creation (hence the createTab() hook), iterate over the TabContents' sections and set the root entry in the desired sections. In our subclass of AdvancedPropertySection, we override createPropertySheetPage() and finally call page.setRootEntry(ourRootEntry). Alas, I haven't found a better way to pass something from the outside to a specific PropertySheetPage.
OK, I get it, I looked at your patch again, you just need to be able to override the one line: - tab = (descriptors[i]).createTab(); + tab = createTab(descriptors[i]);
(In reply to comment #33) > OK, I get it, I looked at your patch again, you just need to be able to > override the one line: > > - tab = (descriptors[i]).createTab(); > + tab = createTab(descriptors[i]); Yup, exactly.
Created attachment 75144 [details] Patch for Dynamic Tab and Section Support Updated patch based on Carsten's comments. Completed JUnit tests and JavaDoc updates.
Created attachment 75227 [details] Icons for Dynamic Tests View
(In reply to comment #35) > Created an attachment (id=75144) [details] > Patch for Dynamic Tab and Section Support Good job, works great. Only one question: AbstractSectionDescriptor now expects an ITypeMapper in its constructor. Is it ok to pass null, as e.g. TextTestsSectionDescriptor does? If so, then it might be worthwhile to provide default constructor or at least document that null is a valid value. Thanks, Carsten
(In reply to comment #37) > Good job, works great. Only one question: AbstractSectionDescriptor now expects > an ITypeMapper in its constructor. Is it ok to pass null, as e.g. > TextTestsSectionDescriptor does? If so, then it might be worthwhile to provide > default constructor or at least document that null is a valid value. I have added a default constructor for AbstractSectionDescriptor without a type mapper since it can be null (an user does not need a type mapper).
Created attachment 77282 [details] Override tests view I am attaching am image for the final set of JUtests for this enhancement. Override Tests View shows the migration from a TabFolder/TabItem framework to the tabbed properties view. This allows us to complete Bug 131862 and move users from the WTP DynamicTabListContentProvider to the Eclipse tabbed properties view. I had an internal IBM examples based on WTP, so I created some JUnit tests that does the same thing the examples did. The OverrideTestsView example is a look at the properties view after the migration of a TabFolder/TabItem framework to the tabbed properties view. In the case of a TabFolder, the folder (provider) knows both the tab labels and tab items. This aligns to the tabbed properties view, but the tab labels are tab descriptors and tab items are section descriptions. This does not work with the default framework as the tabs provide the sections. In this case, the our new dynamic tabs and sections framework has been provided. Note that the overridable tab list is a content provider that provides both the sections and the tab labels (similar to what WTP supported).
Created attachment 77284 [details] Override tests view the correct image file
Committed to HEAD
> Committed to HEAD Excellent, thanks!
Hi guys, this feature is nice. But I have problems to understand it completely. Let's say, I just need change some tab labels based on a selection. So I can't use the "static" way with tabs and section contributed using extension points, but I have to provide my own ITabDescriptorProvider, right? I also have to implement all those ITabDescriptors and even ISectionDescriptors because the registry is now obtaining the sections from ITabDescriptors provided by my ITabDescriptorProvider and sections contributed through propertySections extension points are ignored. What if someone else in its own plugin would like to extend any of my tab? Or even add its own tab? With the "static way" it was easy, but how can one archive this with "dynamic" way? Thanks
