Community
Participate
Working Groups
I would like to make a custom sorter for the CommonNavigator. I have extend the org.eclipse.ui.views and defined a view of mine (called ConfigurationView) that uses the org.eclipse.ui.navigator.CommonNavigator as its class. I have also extend org.eclipse.ui.navigator.viewer and defined the corresponding viewerContentBinding. As a viewerContentBinding I have set org.eclipse.ui.navigator.resourceContent. This way my ConfigurationView looks just like the Project Explorer. What I would like to do is to sort the members in the ConfigurationView by their extension, not by their name(as this is the default)... The problem here is that you can only sort the children of the navigatorContent providers that you have defined. You can not sort the children of org.eclipse.ui.navigator.resourceContent extension.
The Common Navigator framework does not support overriding sorting for already defined extensions. The root issue here is that there is no seemingly intuitive behavior here; for instance, if more than one client attempts to override the sorting for a given extension, which one should win? Priority is not a valid solution here. In the next release, it may be possible to expose "sorting strategies" that might have knowledge of several extensions, and users could select which strategies made sense for their current work environment. What would you expect in your use case? If you and another contributor had a situation where you overrode the sorting, what behavior would you expect?
I can see two sides to this request. Firstly, from the user's standpoint, I could reasonably expect to be able to choose how the resources of the resourceContent extension are sorted. Most file browsers in windows support sorting by name or extension. Neither the Resource Navigator or the resource content extension of the Project Explorer support this but perhaps they should. Secondly, when using the resource content extension in other views, I think it would be reasonable for the client to specifiy the default sorting to be used by the navigator content extension. I don't see this as providing a custom sorter as requested in the original comment. Instead, I see it as information that needs to be included somehow in the viewerContentBinding (or some relatd XML). The point is comment 1 about a "common" sorting strategy is interesting as well. Other content extensions may also sort resources and would need to know about the request to sort by extension. This would imply that the setting would need to be associated with the viewer. Another setting that is similar to sorting is that of presentation (e.g. Flat vs. Hierarchical). It is my understanding that, as it stands now, each content extension needs to provide it's own configurability for this setting, which could lead to multiple occurances of Presentation menu items in a single viewer. The UI would be simplified if there was a single presentation setting. The bad news is that making these things common could restrict the available settings (i.e. a model may have additional presentations that are not in the common set of Flat and Hierarchical).
Providing configurable sorting for the resources extension is something that I think could be containable for 3.2.1. The setting could default based on the viewer definition using the viewer properties (which are inherently designed to support cases like this). So it wouldn't be declared by the viewerContentBinding, but rather the viewer element. Currently viewerContentBindings cannot specify their own viewer properties. It wouldn't be impossible to implement, but I wouldn't support it as a feature for 3.2.1 without significant community feedback that it would be extremely useful. A customizeable, resource-extension specific sorting option would imply that a certain limited set of sorting options would be available for the resource extension. Downstream clients could not define their own sorting mechanisms; they could only indicate which one they would like to use (specifying a default in the viewer definition, and then possibly an option for whether the option should be exposed to users via a viewer toolbar drop down). I would see the following as possible sorting options for resources: (1) sort by name (2) sort by extension (3) sort by type* (4) sort by modified (would this be useful for users?) *The type one is going to be a little tricky since a user will expect that the Java elements will respect this setting, when in reality any generic resource sorting would be overridden by the Java sorting scheme. To support this in environments that have both Resource/Java content (or C++, PHP, whatever); they would all need to be aware of this sorting setting and respond accordingly. This may not be containable for 3.2.1.
From my point of view sorting any view is not a critical part for most of the applications. Sorting just makes the user fill more comfortable and simplifies his work. So I think that the user must chose the type of sorting. This is mentioned in comment 3. Provide some type of sorting (like by name, by extension, by size, etc) and leave the user to choose the sorter he feels comfortable with. This way contributors can not sort the children of a navigatorContent not defined by them. For every content provider the user chooses to use in "Filters -Available Content" he must also choose the sorted to be used with this provider. On the other hand I can think of many ways to sort the files in the viewer: - by name/ and reverse - by size/ and reverse - by modified/and reverse - by extension/and reverse - by extension - but in specific order (like first *.java, then *.jpg then *.anything. - by the number of characters in the name of the file / and reverse and ofcouser many more. Giving the power for sorting to the contributor so he can implement any kind of sorting he can thing of will be something great. So i thought: i will leave the org.eclipse.ui.navigator.resourceContent and provider my viewer with a navigatorContent that is exactly the same as the org.eclipse.ui.navigator.resourceContent but with different commonSorter. But the content and label providers of org.eclipse.ui.navigator.resourceContent are bouth in internal packages.
My 2 cents: I don't think we need to consider addessing this for 3.2.1 especially considering that the Resource Navigator doesn't support customizable sorting. However, it would be worthwhile to consider doing something in 3.3.
(In reply to comment #3) "Item (4) sort by modified" is very important for our seismic processing RCP application. I'm working with Eclipse 3.3 and I'm seeing one issue with the WorkbenchContentProvider. The WorkbenchContentProvider ignores IResourceDelta.CONTENT changes. A file content change does not force a sort.
I'd definately find it useful for my application if this could be fixed. If I create my own Viewer I can call setComparator and sort however I like... but not if I'm using CommonNavigator. Maybe (as suggested by Michael above) a simple addition to the "viewer" extension point so that a custom sorter/comparator class could be provided if desired. Just this would provide enormous flexibility for anyone with custom sorting requirements to do whatever they need, and also doesn't seem like too much work (i.e. just call setSorter() or setComparator() with the specified class, if the extension/property is set for the viewer).
Has there been any enhancements added with regards to this since the original submission?
I guess I can see two things to do here: 1) Allow the CommonViewer sorting to be specified, so that you have all of the same options as you would for a normal viewer (https://bugs.eclipse.org/bugs/show_bug.cgi?id=141724#c7). 2) Allow navigatorContent extensions that only specify sorting (that is, make the specification of label and content providers optional). Using this mechanism, you can override the resource related navigatorContent extensions to specify your own sorting. The priority mechanism would be used to handle cases where multiple extensions are overriding, so there might be a problem there in some cases, but refining the priority mechanism to better deal with this type of problem is the subject of another bug. Would this satisfy people's concerns? Comments?
We need to be careful here as this might break navigatorContent providers which up to know could assume their sorting being applied.
Any development on this? In my case, I have added my own navigator content extensions with their own content provider and label provider. In the label provider, I return a textual label for some type of resources which is date. Since the resources are ordered according to the file name, the current order is totally useless for the user. I don't quite understand why I'm able to override the label for these resources but not the sorter.
*** Bug 162330 has been marked as a duplicate of this bug. ***
As mentioned in comment 9, the solution so this will be to allow an NCE to not specify a content or label provider but only to specify a common sorter. The current sorting algorithm selects the sorter to apply based on the NCE that contributed the object being sorted, even if that's an overriding NCE. It then looks for the common sorder within the NCE that matches the parent of the object being sorted, the first one wins. The new sorter override capability will process the NCEs with sorters and no label/content providers (sort-only NCEs) along with the NCE that contributed the object, in sequence number order (the sequence number is calculated based on both the priority of the NCE and the new appearsBefore attribute, allowing an NCE to require that it be in front of another). The first sorter that matches the parent wins, as previously. This means the winning NCE may be before the NCE contributing object, or even after it. I will also implement the suggestion of allowing a sorter/comparator to be specified on the CommonViewer. I think with both of these capabilities we will have the basic plumbing for a flexible sorter override mechanism. Later we can add some UI around it to allow the users to have some choices as far as what's enabled.
I decided not to do the change to allow any sorting specification in the CommonViewer, as the sorting overriding mechanism should be sufficiently flexible to allow override of sorting at a global level if necessary, and there is additional complexity associated with altering the sorting of the viewer. Released to HEAD, 3.6M6
Verified in I20100310-1800, the associated tests pass
