Community
Participate
Working Groups
How come the PropertyViewer hard-codes alphabetical sorting of properties based on the property name? What if I want a different order? Why don't we just display them in the order they are given by the property source? It should at least use the IViewerSorter mechanism that is part of the Viewer framework... NOTES: I second this PR. In PDE, I would like required attributes to appear first and then optional ones (because required are more important and must be set). In addition, I would like to order attributes the way they are defined in the extension point, which is generally not alphabetical.
From Randy Hudson. The original propertysheet had a merger object that would both merge and order the property descriptors. In my current project I will need to display in the propertysheet: + Location - x - y - width - height. and I don't want it to read height, width, x y. categories won't help either.
Defer until development resources are available to properly consider this request.
Reopened for investigation
*** Bug 35948 has been marked as a duplicate of this bug. ***
I feel it's important to have a sorter for the pages
Control over the "sorting" of the properties is something we would like to see as well. Right now, we're forced to rename the properties just to make them display in the order we want. For example, in the case listed earlier by Randy G. (on behalf of Randy H.), the desired order could be forced by renaming the "x" and "y" to "coordinate x" and "coordinate y". We are going through similar gyrations right now.
Rather than sort the properties, it obviously much more flexible to have them appear in the order in which they were entered into the propertyDescriptor array. Renaming my properties so that they appear in the right order is surely out of the question. I would see most ppl. placing important properties first and the alphabetical sorting totally ruins it. I'll have my users eating my brains yet...
This also presents an issue for translation/internationalization of property names. The order in which they appear should be controllable by the code adding those properties, regardless of the alphabetical order of the names.
This bug really detracts from the usefulness of the property sheet. Please adjust priority. I'm sure anyone on the CC list could provide a patch to fix this problem, if it would be committed. One possibility is to place an A->Z action on the propertysheet which enables and disables sorting. But, how would you store that preference? globally? per part type? I would favor not giving the user control, because once you do that, you will incorrectly guess which mode they want to use for a given editor. Another alternative is to add to IPropertySource: /** * returns <code>true</code> if the descriptors * should be sorted by their name. */ boolean sortPropertyDescriptors(); And yet another, add to IPropertyDescriptor: /** * returns the integer value which determines the primary * sort order for descriptors. Descriptors with the same priority * will then be sorted by their name (in the current locale). */ int getPropertyPriority(); Maybe the last proposal is the best?
Adding MVM to CC because I'm not sure if this is on UI team's radar. I suspect adding methods to IPropertySource is out of the question because it would be a breaking change to all clients, but there could be a new sub-interface.
The easiest solution would be to just have the PropertyViewer display the properties in the order they are provided in the IPropertyDescriptor array that comes back from the getPropertyDescriptors() method of the IPropertySource. If that isn't an option, how about an extended interface (IOrderedPropertySource?) that can be checked for in the PropertyViewer code, with new methods to control the ordering of the properties?
The reason I suggested putting the sorting info on the descriptors is that it would avoid conflicting orderings. 2 different property sources might return different orderings for the same properties. Also, from an *implementation* standpoint, sometimes property descriptors are obtained by going to multiple delegates. If each delegate wants control over where its descriptors are placed, the best way to indicate this is on the descriptor. That way, the property source could just concatenate all of the delegates' contributions without worrying about order. See bug 21756. The IPropertySource interface is flawed and requires breaking changes anyway. But I still prefer changing/extending IPropertyDescriptor. Isn't there still time (M6) for breaking changes?
*** Bug 44800 has been marked as a duplicate of this bug. ***
geez, I cannot believe this did not make it into 3.0. It is unacceptable. As one person noted below "his users will eat his brains".
Use case suggestion: I have a requirement to order properties based on a value which is not (necessarily) part of the property label or property value. In this case it's the non-internationalised version of the label-string, but it's possibly a good illustration of why sorting based just on content (rather than some external field) may not be a complete solution.
would anyone care to provide a patch and a test case?
What about solvint this the following way: Add an additional interface IPropertySourceSort. Then check to see if the property source implements that interface (or is adaptable to it) and call the property source to do the sort. By default if the interface is not implemented, sorting is as today. If you implement the interface and do nothing (do not sort) you should get the order the property descriptors are added, or implement the methods and sort in any manner you choose. public interface IPropertySourceSort { sortProperties( List propertyDescriptors ); sortCategories( List propertySheetCategories); }
Why cant we just switch off the current default alphabetical sorting done by the property sheet code. That solves half the problem.Let the property sheet show the properties in the order the property descriptors are sent. There was a use case here from rich boakes:" sorting based just on content (rather than some external field) may not be a complete solution"..Here is the solution,let the user sort his descriptors based on whatever logic he desires. And let him send this in the getDescriptors(). getDescriptors() is queried everytime an element is selected.So if u want to show a different set of properties,or u want to show the same properties in different order,all u got to do it is recompute it and sent the new descriptors list. So user has absolute control over the way his properties are to be displayed. [That is Once u remove the sorting code from the property sheet]. This way u need no api breaking changes,no new interfaces.
I agree with the last comment "just switch off" how hard can that be? Oh ya I've already done that, stopped using the property sheet.
Just switching it off would change the behavior of plugins that are used to it having been sorted since 1.0.
I doubt it. I dont think property sheet is widely used.Its importance can be guaged from the fact that out of more than a million downloads,probably all the guys who are interested in the property sheet can be found in this mailing list!!! Eclipse1.0 had editors as its main feature .And people who had used eclipse1.0 for developement would have used it for developing custom text editors,which doesnt require much property sheet support.[Well i guess atleast 90% of the guys].In eclipse2.0 alongwith GEF,came a host of new features,providing graphical editors etc.Here property sheet gained a bit more prominence.But i still doubt if many people used it extensively. Also its importance can be guaged from the fact that the eclipse team has not made any major changes to it since 1.0 days. The point i am trying to make is eclipse property sheet hasnt been used widely for development by users,and there is ample scope for making changes to it without affecting them. Even if considering the case where there are users who do get affected by this "swich off",the changes they have to make to their code are trivial. Now consider my case:I unfortunately am developing a tool that uses property sheet extensively. I will tell u my very simple usecase.I got a set of properties that i got to show in a set order. I do not require alphabetical sorting or any sorting.Now to solve this there is no way for me to switch off the default sorting,i cannot extend/reuse the property sheet becoz 90% of the classes/methods are package/private protected.Now to solve this simple usecase and becoz of 10 lines of [unwanted]sorting code,i ended up rewriting the whole PropertySheetEntry class!!! I got another point:How do u propose to solve this bug?? 99% u will introduce a new interface somewhere which the client's got to implement.And then u will pass the control to the client to do whatever he wants with it.My point is this :I already have control in IpropertySource.getDescriptors().I can do whatever i want there and return it back.Now why do u want me to implement a new interface for doing the same thing??
Ross Yakulis suggestion from comment <a href="#c17">17</a> would certainly fulfil any issues I highlighted in comment <a href="#c15">15</a>. For the sake of API simplicity I'd also vote for the creation of a combined sort-aware properties interface; giving developers time to migrate to the new API through the deprecation process.
There's no reason to implement anything new. Just create a new interface (such as IOrderedPropertySource) that extends IPropertySource, and add in the the code to "detect" whether that interface is being used. If it is, disable the sorting, and use the order of the items that come back from the getDescriptors() method. Then the only thing that would need to be changed in the code for plugins that want to disable the sorting is to change the base interface they are implementing from IPropertySource to IOrderedPropertySource. Problem solved. FYI, we've worked around this problem by numbering the property names (01, 02, 03, etc.) to get the desired order from the sort.
It's not simply done by adding a new interface for IPropertySource. Sorting is not task of the IPropertySource but of the PropertySheetPage and its root IPropertySheetEntry respectively. Note, that there may be multiple property sources selected. In this case sorting might be different. The easiest way is to provide your customized IPropertySheetPage but this is only possible if you provide your own views and editors. I'm investigating.
Gunnar, I don't see why each property source cannot return compatible orderings with respect to property descriptors. If fact, the user would probably expect this even if the editor only allowed single selection. I don't see any problem with trusting the IPropertySource's descriptor order. There are several ways to do this. Another way is to add an extension to IPropertyDescriptor to allow it to provide an alternative String to use during the sort. It's all the same thing. I guess another question is whether an "Alphabetize" action is needed to toggle between alphabeticl and "implicit" ordering.
Yep, but I'd like to have a more generic solution. What about a "Sort" menu inside the view's menu? An IPropertyDescriptorSorter which can be implemented by any IPropertySource, provided by an IPropertySourceProvider or attached to PropertySheetPage and/or PropertySheetEntry? The "Sort" menu would list all detected IPropertyDescriptorSorter and the user can choose between different sorters. The "natural" and "alphabetical" sorters will be provided by default. Default sorter lookup would up be: PropertySheetEntry (IPropertySource) -> PropertySheetPage -> Alphabetical (for backward compatibility)
See http://www.eclipse.org/webtools/initial- contribution/IBM/evalGuides/TabbedPropertyEval.html?p=1 for a proposal of an extended properties view. It's interesting to see that even IBM is considering an enhanced Properties view. However I had some other extensions in mind an will start a discussion on the mailing lists to integrate an enhanced Properties view into the Eclipse Platform.
Please see http://javadude.com/eclipse/sortingpropertysheetentries.html for a somewhat hackish method of allowing folks to override the sort order. It sounds like this is may take some time to get a proper resolution, so I'd recommend making the change I suggest in bug # 24694 (create a protected createChildEntry() method in PropertySheetEntry and call it from createChildEntries instead of "new PropertySheetEntry"). I've attached a copy of PropertySheetEntry with this change. GEF uses a combo of template method and factory method to allow this approach.
Created attachment 13943 [details] PropertySheetEntry with protected createChildEntry() method This is an example of using template method and factory method to allow subclasses of PropertySheetEntry. Such subclasses can be used to allow custom sort order by prefixing the property display names as outlined in http://javadude.com/eclipse/sortingpropertysheetentries.html.
What about extending the view--add a button to the view (view action) to enable/disable sorting. The Java editor outline content page does something similar where you can sort by method name. This would allow people who prefer properties to be sorted, to have them sorted; and for the rest of us, they can be unsorted--plus it allows the user to control the order of the properties as they prefer rather than the developer.
In the properties view I would like to see, that you can sort the properties and the categories(!!!) in custom order.
It's my turn to be surprised that so annoying limitation is out of developer's control. Unfortunately, P4 priority assigned to this bug, is not very promising although the fixing of the problem does not seem to be difficult.
Created attachment 17897 [details] Patch that adds sorting to PropertySheetPage I talked to Nick and we agreed to prepare a patch for this to hopefully get it into 3.1. This is a first proposal. It adds sorting to the PropertySheetPage (and thus the PropertySheetViewer) using a PropertySheetSorter. Subclasses of PropertySheetSorter can overwrite the compare methods to provide a different sorting for IPropertySheetEntry entries and categories. Sorting is not performed in the PropertySheetEntry anymore. It's not done in the viewer. This approach is similar to the ViewerSorter concept but does not use the ViewerSorter class because it doesn't really fit into this usecase. The PropertySheetViewer isn't public API anyway. Example usage: public class MyViewPart extends ViewPart { ... public Object getAdapter(Class key) { if (IPropertySheetPage.class.eqauals(key)) { PropertySheetPage myPropertySheetPage = new PropertySheetPage(); myPropertySheetPage.setSorter(new MyPropertySheetSorter()); return myPropertySheetPage; } return super.getAdapter(key); } } class MyPropertySheetSorter extends PropertySheetSorter { public int compare(IPropertySheetEntry entryA, IPropertySheetEntry entryB) { // your custom sorting return 0; } }
(In reply to comment #21) > I got another point:How do u propose to solve this bug?? 99% u will introduce a > new interface somewhere which the client's got to implement.And then u will > pass the control to the client to do whatever he wants with it.My point is > this :I already have control in IpropertySource.getDescriptors().I can do > whatever i want there and return it back.Now why do u want me to implement a > new interface for doing the same thing?? Well that doesn't work. A user can select multiple elements in a view or an editor. The properties view handles this by merging all property descriptors of the elements and showing only those which are shared within all elements (based on the descriptor id). Which sorting should be used then? In any case it's not unique leading to unexpected results in the UI which confuses users. That's why sorting is a typical task for viewers.
Hi Gunnar, Wasn't thinking of getting a comment after a long gap..:)-.. PropertySheetPage.setSorter() is a breaking change right??Its a new api being introduced..Since u r introducing breaking changes,probably u can work on introducing some more new functionality!!. If u r interested take a look at bug 53842 regarding some more property sheet use cases.[I had also provided some patches for these.]
Thanks Gunnar. I'll review these for M6. Zenil: Adding a method to a subclassable class is not a breaking API change as long as it's not an abstract method.
Yes,used the wrong term.Its a new api. (In reply to comment #36) > Thanks Gunnar. I'll review these for M6. > > Zenil: Adding a method to a subclassable class is not a breaking API change as > long as it's not an abstract method. >
Has anyone interested in this problem tried Gunnar's patches? I'm reviewing them now, but if others have feedback, now is the time to comment.
OK, how to get it?
Since it's not yet released: - load org.eclipse.ui.views from CVS (see http://www.eclipse.org/eclipse/faq/eclipse-faq.html#users_7) - save the patch from here to a file - select the project and choose Team > Apply Patch, and select the file - choose Guess since there have been some code changes since the patch was applied, and the line numbers are off - apply the patch and try it
Almost fine :-) I used it in a little bit different way (is it correct?): my view: public class SystemBuilderPropertiesView extends PropertySheet { protected void initPage(IPageBookViewPage page) { super.initPage(page); if(page instanceof PropertySheetPage) { ((PropertySheetPage)page).setSorter(new SystemBuilderPropertySheetSorter()); } } } my sorter: public class SystemBuilderPropertySheetSorter extends PropertySheetSorter { public int compare(IPropertySheetEntry entryA, IPropertySheetEntry entryB) { // TODO Auto-generated method stub // return super.compare(entryA, entryB); return 0; } public int compareCategories(String categoryA, String categoryB) { // TODO Auto-generated method stub // return super.compareCategories(categoryA, categoryB); return 0; } } It's clear from my code that I would like to keep everything unsorted. Unfortunatelly, PropertySheetViewer.updateCategories() uses: // Sort the categories Collection categoryCacheValues = categoryCache.values(); categories = (PropertySheetCategory[]) categoryCacheValues .toArray(new PropertySheetCategory[categoryCacheValues.size()]); sorter.sort(categories); toArray() just changes the original order, so even if I don't do anything in compare..., I get the categories order different in comparing with original.
Alex, you should not need to create your own properties views (this defeats the benefit of having a single Properties view). It should suffice for the source part to set the sorter on the PropertySheetPage it provides (and this should not be overridden by the Properties view). Gunnar, maybe PropertySheetPage.setSorter should be protected, to avoid this misuse. The fact that the category order is not maintained when you make the sorter do nothing is a real problem, and is due to how the code to reuse categories worked before Gunnar's patch.
Sorting patch reviewed and applied, with the following changes: - made PropertySheetViewer.updateCategories only assign categories field after sorting succeeds - made PropertySheetSorter no longer subclass ViewerSorter (it's got a different contract, and the ViewerSorter API is not used) - made PropertySheetPage.setSorter(PropertySheetSorter) be protected, as per comment 42 - fixed up the hash map ordering problems (for both descriptors and categories) that were causing the problems for the "no sorting" case in comment 41 - add missing @since 3.1 tags - included title from this bug in the attribution comments While this solution requires the source part to provide a custom property sheet page, this seems like the only tractible approach (see comment 34). Marking as fixed.
Verified in I20050331-0800.
(In reply to comment #43) > - made PropertySheetPage.setSorter(PropertySheetSorter) be protected, as per > comment 42 > While this solution requires the source part to provide a custom property sheet > page, this seems like the only tractible approach (see comment 34). > Marking as fixed. In above comments, it seemed we need extend PropertySheetPage, but in PropertySheetPage's javadoc, it says "This class may be instantiated; it is not intended to be subclassed."
I've captured this oversight as bug 109617.
