it's currently weighted as per current design spec, with third party plugins defaulting to end of list when a weight isn't provided.

need UI design decision on this one.  

I think I'd prefer an alphabetical list for now because without doing some user research, there's no real way to determine what order it should be in that would be best for the user

This gets rid of the use of sorting by rank prefs

Index: C:/slim/server/Slim/Buttons/Home.pm
===================================================================
--- C:/slim/server/Slim/Buttons/Home.pm	(revision 18130)
+++ C:/slim/server/Slim/Buttons/Home.pm	(working copy)
@@ -527,9 +527,7 @@
 
 	my @list = ();
 
-	for my $sub (sort {(($prefs->get("rank-$b") || 0) <=> 
-		($prefs->get("rank-$a") || 0)) || 
-		(lc(cmpString($client, $a)) cmp lc(cmpString($client, $b)))} 
+	for my $sub (sort {(lc(cmpString($client, $a)) cmp lc(cmpString($client, $b)))} 
 		keys %{$params->{'submenus'}}) {
 
 		# Leakage of the DigitalInput plugin..

It's Dean's call.

Please sort alphabetically.

KDF will you do the honors?

change 18233, hopefully to the correct repo :)

This is no good, I thought we were following Dean's order listed here: http://wiki.slimdevices.com/index.cgi?UserInterfaceHierarchy

Music Library especially is all messed up now.  And having Staff Picks as the last item in Radio feels wrong.

gagh.  I hate all this redefining lately.  These will have to use the same weighting system used with squeezeplay so that weighted menus will work just like the controller/web views, while Extras menu alone remains asphbetical

reverted 18233 for now. sorry.

change 18346 does a better job, sorting only the extras menu alphabetically.  This sticks with the wiki in all other menus and matches what the web and squeezeplay UIs are doing.  Leaving open for now in case someone prefers it to be done in a different way.

Thanks, I think this will probably be fine, so marking fixed.

(In reply to comment #12)
> Thanks, I think this will probably be fine, so marking fixed.
> 

Marking bug as closed, unless we want to do more redefining of the spec

Reduce number of active targets for SC