Community
Participate
Working Groups
* Install RSE core and ssh-only from update site * Restart from Update Manager * Create an SSH connection, and connect it * Install dstore from update site * Restart from Update Manager Now, create a new connection of type "Linux". Usually, always "dstore.files" is the first service in the files subsystem page, and preselected by default. But in the scenario above, "ssh.files" is preselected. This can lead to confusion and surprising results, when the user would normally expect dstore but gets ssh. I think that the ordering of services in any given page of the new connection wizard should always be the same. I propose sorting the services by name, so it's alwyas "dstore.files" then "ftp.files" then "ssh.files". -----------Enter bugs above this line----------- RSE 1.0 Release Test installation : eclipse-platform-I20061121-1845 RSE install : update-site RSE M20061123-0700 java.runtime : Sun 1.5.0_08-b03 os.name: : Windows XP 5.1, Service Pack 1 ------------------------------------------------ systemtype : Ssh, Dstore ------------------------------------------------
This should be looked at late in 2.0. It is related to bug 176490, because in case that one is addressed the ordering does not matter any more.
Reproduced again with I20070405-0600 on windows. Installed runtime-core,local,ssh,ftp first and then got dstore from the update site --> dstore was listed last. I think it would be best to have the services sorted alphabetically in the wizard pages. Note that if bug 176490 (generic wizard improvements) should be fixed, this is not an issue any more.
*** Bug 196506 has been marked as a duplicate of this bug. ***
I was never seeing this problem before, but using my dev driver now I see it 100% of the time. Creating new workspaces and it's still the default. Xuan synced up and saw this problem as well. Are we sure nobody has changed something that would effect this as it looks like a regression. Even if it was possible to do it before it's always happening now.
Yes I'm also consistently getting ftp.files first now. The reason for the change from "sometimes" to "always" could be that because of the changes we have made, version numbers were updated: - ftp.files and ssh.files are still at version 2.0.0.qualifier since we did not change anything in the 2.0.1 stream in those plugins yet - dstore.files is at version 2.0.1.qualifier since it was already changed Again, I think the problem is that we do not really impose any kind of ordering on the services being shown, so we are subject to getting whatever bundle the Eclipse Platform / Extension Registry gives us first. I think that we must ensure proper ordering ourselves (e.g. by sorting alphabetically).
For the sorting in the view, we could just use a ViewerSorter in the ServicesForm: _factoryViewer.setSorter(new ViewerSorter()); This doesn't address the default selection though. For selection, we're currently using the default based on the current configuration, which was supplied with the property page. This default configuration is determined by SystemRegistry.getSubSystemConfigurationsBySystemType(). I guess we should change how we select the default, at least in the wizard.
I could also imagine sorting in SystemRegistry.getSubSystemConfigurationsBySystemType() since it's always good to have deterministic results of functions.
(In reply to comment #7) > I could also imagine sorting in > SystemRegistry.getSubSystemConfigurationsBySystemType() > since it's always good to have deterministic results of functions. > If we did it in there, then this would be a much easier problem to solve. I guess there's no way to be deterministic about the order of loading for the configuration extensions.
I've gone with Martin's suggestion and changed SystemRegistry.getSubSystemConfigurationsBySystemType().
The fix is invalid because it sorts SubSystemConfiguration by getName() rather than getId() attribute. But the name is translatable and need not be unique. ftp.files and dstore.files both have a name saying "Files", therefore sorting them by name still does not make the result deterministic. They must be sorted by Id instead.
Created attachment 74361 [details] Patch to sort Subsystem Configurations by Id Attached patch fixes the issue by already sorting the internal SubSystemConfigurationProxy[] array by Id. That way, all results of all getSubsystemConfiguration*() queries will always return deterministic, sorted results without any extra overhead for sorting. Note that accessing the Id from the static Proxy is valid as per bug #196942 -- overriding SubSystemConfiguration.getId() in a subclass would have always been invalid because it must be consistent with the Proxy and the Javadoc has always said so.
Patch committed: [165674] Sort subsystem configurations by Id rather than name SystemRegistry Please review, and note how short and elegant the code can be by using Object[].clone() Arrays.sort() Comparator
Released for I20070723
Now the New Connection subsystems configuration wizards are in a different order. Windows Connection -> Shells -> Files Linux Connection -> Files -> Processes -> Shells Unix -> Files -> Processes -> Shells
I see... it's because the ID for dstore windows files is dstore.windows.files which sorts AFTER dstore.shells I think that this should be fixed by honoring the "priority" attribute of the subsystemConfigurations extension point in order to create a proper sorting when the wizard pages are created. Note that this is already the way how we ensure proper sorting of the subsystems in the SystemView, as per bug #149280 Also note that a similar change of ordering of pages could have happened even with the previous version of the code before my fix, if a translator decided to give the subsystems names which sorted differently in that different language (e.g. "Commandos" vs. "Dateien" in german). Reopening to implement that change.
Created attachment 74368 [details] Additional patch to sort by Priority then Id The additional patch sorts by Priority then Id. Note how simple that fix is, thanks to using Comparator! It is very likely that with this fix, the original fix for bug #149280 can also be removed.
Patch applied -- thanks Kevin for noticing the issue. [165674] Sort subsystem configurations by priority then Id SystemRegistry
Created attachment 74369 [details] Simplified patch re-using SubSystemConfigurationProxyComparator The fix is even simpler and duplicate code can be avoided, by re-using SubSystemConfigurationProxyComparator. I'm checking in these final changes: [165674] Sort subsystem configurations by priority then Id SystemRegistry RSECorePlugin SubSystemConfigurationProxyComparator
