Community
Participate
Working Groups
The Referenced Projects box in the New Project wizard sorts project names in binary order. (For example, "B" comes before "a".) It should instead use the default collator for the current locale, as the Project References property page and the Resource Navigator do.
Created attachment 47708 [details] Fixes the bug by setting a sorter
Created attachment 48321 [details] Fixes the bug by setting a sorter; respects import conventions
Unfortunately it's not that simple. In 3.2, Eclipse began to adopt using the ICU4J collator (it's better than Java's Collator under a wider range of locales). The more correct fix is to set the viewer's sorter to take an ICU collator using the setComparator() method on the viewer (this API was added in 3.2 to support using ICU4J's Collator). When looking at this bug, I also noticed that the IDE is not setting a comparator using JFace's Policy#setComparator method so that the ide uses ICU4J's Collator by default. The consequence of this is if you create a ViewerComparator with the no-arg constructor, the sorting will yield the same result as is currently, without a sorter set on the viewer.
Created attachment 48331 [details] apply patch to org.eclipse.ui.ide Here is a patch that contains the changes to do what i discussed in my last comment.
released changes to HEAD for build > 20060822
Created attachment 48468 [details] Don't wrap the ICU collator Unfortunately, I don't think it's /that/ simple either: - There is no need to wrap the ICU collator in another comparator that converts objects to strings since the JFace documentation says the comparator will only be used on strings. The attached patch removes the wrapping. - The Project References property page that I mentioned is still using the "viewer.setSorter(new ViewerSorter())" technique. If it is most correct to use a ViewerComparator, the property page needs to be changed. As I was investigating what you did in your patch, I came to the conclusion that the arbitrary-comparator API introduced in 3.2 is very badly designed. It would be much better to allow a ViewerSorter to have an arbitrary comparator and kludge ViewerSorter.getCollator() than to introduce ViewerComparator, kludge StructuredViewer.getSorter(), and commit to eventually changing all references to ViewerSorter to use ViewerComparator. I understand that API methods from before 3.2 that return Java collators must continue to work, but I hope there is a chance of redesigning the arbitrary-comparator API, especially because only two classes outside of JFace itself are using the API so far. I will file a separate bug.
My complaint about the API is in bug 154871.
Yes, it was overkill for me to implement my own comparator so I changed that code. I am not sure what you are referring to when you say the project references page is still using viewer.setSorter(new ViewerSorter()) - I released the setComparator(new ViewerComparator()) code from my patch to HEAD. I realize the design seems confusing. We faced several restrictions when designing this: don't break existing API, don't add a dependency on ICU in JFace, don't break function. The root of the problem we faced when designing this was the public method ViewerSorter#getCollator that returns a java.text.Collator. Eclipse doesn't break APIs so removing the method or changing the return type was not an option. If we were to add a comparator to ViewerSorter, getCollator() would return null when a comparator was used, which alters the current behavior of getCollator (it always returns something that is not null - callers of this method rely on this).
org.eclipse.ui.internal.ide.dialogs.ProjectReferencePage is still using ViewerSorter, but before you change it, let's finish discussing the API on bug 154871.
verified in I20060918-2000
