Created attachment 2825 [details]
implement the first part of the request

This only fixes the first part of the request -- showing the # for each Favorite in the web UI.

the re-order is drag and drop once you click the pencil icon at the right of the 'favorites' section header.

We'd probably only want to add the number to the first level, as the other level's aren't available from the remote. And don't add the # in front of it - we don't use it in Switzerland ;-)

change 17537 - add numbers to the menu

In the web UI this is big time ugly and actually a visual obstacle to quickly identifying and playing favorites.  Can this change be reverted?

I can't reopen this bug - haven't got permission...

This "fix" has introduced a bug in the numbering; the hierarchy numbers are not calculated properly.

The number hierarchy is really messy and wrong.  I have favorite #1 - Radio Stations, containing a hierarchy of radio stations:

1: Radio Stations
	1: Electronic
		1: Groove Salad | Ambient Beats and Grooves
		1: Stillstream
	1.1: DJ Sonix
	1.2: Prog Rock
		1.2: Aural Moon
		1.2: Delicious Agony
		1.2: ProgRock.com
	1.3: Sport
		1.3: Talk Sport
		1.3: Radio 5 Live

If we really must have the numbers prominently visible in the web UI, can I suggest it is only for ones that are bound to hotkeys?  I'd prefer it if the number were within the properties of a favorite item, or formatted to be at the end of the favorite name.  eg. "My Favorite [1]".  This display formatting would make more sense if in the future the hotkey numbers were manually assignable (not automatically associated with the position of the favorites in the list).

The only possible relevant numbers are 1-10, as these map to keys on the standard remote.
What relevance would favorite number 11 have?  You can't press digit 11 on the remote!

Also, there is no point showing numbers on items that are not playable (eg. a sub-folder), and no point showing hierarchical numbering (there is no 1.1.2.1 key on the remote either!).

I suggest that this bug is reopened, and the number hierarchy is dropped.  i.e. only display numbers 1-9 and 0 for the first 10 favorite items at the root level, and only if the favorite item type is playable from the hokey (e.g. not a folder).

I will create a separate enhancement request to ask for hotkeys to be manually associated with favorites, rather than the current automatic behaviour.

I think Phil's suggestion is right on target.

I agree with each of the points that Phil makes.  I don't mind so much that the hotkey numbers are displayed if they serve a purpose, but if only 0-9 can be used for hotkeys, then only display those numbers and get rid of all the rest.  I also really like the suggestion that they be displayed in brackets at the end of the links instead of at the beginning.

Michael,

I agree with the discussion here - the currently shown numbers are wrong for sub menus and dont't actually make any sense for these.  I think this need to be changed for 7.0.

Give the timescales I suggest:

1) Remove all numbers for the moment for 7.0 (as there is no time to do any more)
2) Remove numbers from all but the top level menu in Default - i.e. from the favorites page handler as this will remove them from all sub menus where they are wrong.

My personal view is that they clutter the interface and I would prefer we remove them until we can find a better way of only indicating a number for the hot keys as per the discussion on this bug.

For 7.0 they are not doing any harm, though they aren't strictly correct.  Let's fix this in trunk.

If the numbers for the digits is only for indicating shortcuts on the remote, then we should only display digits for the ones that can possibly be used on the remote (i.e. 0-9).

In this case, they should be displayed at the end of the text.  I'd like to see them in brackets i.e. [3], but i'd want to review that UI.  

If we are fixing in trunk I think we ought to do it for bug 7292 at the same time.  The key issue here is that the hotkeys currently use the opml index value [i.e. the position in the opml hierachy].  This is fine if you only have a single level of type 'audio' favorites as it works as the 6.5 scheme worked, however if you mix audio and folders at the top level you get the confusion which is pointed out.

So I think we need to store the hotkey as an opml attribute and not use the index for them, this means they won't change during rearranging of the opml order.  We should then only display the hotkey if it is set and we also need a way to set it from the web interface.  Hence this is a bigger change including some of the internal apis, but I think this would result in a better overal solution.

First step will be to remove the current numbering from trunk though as it's broken...

reverted 17537 at change 17848 - to consider further as part of bug 7292.

numbers are gone again (thanks Triode!) - following up in bug 7292

Verified fixed in 7.0.1 - 19325

This bug has recently been fixed in the latest release of SqueezeCenter 7.0.1

Please try that version, if you still see the error, then reopen this bug.

To download this version, please navigate to: http://www.slimdevices.com/su_downloads.html

Reduce number of active targets for SC