Not only the top menu, but all menus where we control the content.  Keep them, however, for the artists, albums, genres, etc.  Basically any list that we can't predict what will be in the list.

Don't forget that with every device, user requests are to have control over ordering and removal of items in top level and sub level menus.  This means what 'we control' isn't what it may initially seem.

I had a chat with Dean about this. He suggests removing this only on the Now Playing screen.

Yeah I think that's ok...but I think we should remove them from the setup menus too.  That's where we first wanted to axe them

When connected to SC/SN, I'd like to see the "(1 of 8)" string moved to the top-right of the screen, instead of immediately to the right of the top text.

The exception would be when displaying the currently playing song in "Now Playing", where the progress bar or time would replace it.

I'd like to see this tried with the setup menus too, though we may want to handle that differently...

*** Bug 7754 has been marked as a duplicate of this bug. ***

This is easy to do for INPUT.List but less so for INPUT.Choice as it will require the "{count}" token to be treated differently and potentially moved in all callers.  In both modes a callback can define its own overlay for both lines, although the top line is not normally used.  So this would override any overlay defined?

Is this just for Boom or for all players?

Boom only or all players?

I'd say that it should be consistant across all players. I also suggest that when the left sides text is to long, it push the right side text off, as discussed for the long information plugin lines.

Dean that last comment suggest new display code which doesn't force overlays to always be on top?

Could I suggest we put the X of Y in the top right in the existing overlay, but on boom we only show it for a couple of seconds and then suppress it?  I think this would make it look the same for all items in a menu structure rather than it flashing on and off depending on where you are in the menu.  For other players we could show it the whole time.

Now playing is different and wouldn't work with just moving the X of Y to the top right.  However I think we could be considering making far more use of icons for this, to replace now playing, stoped etc.

That's a great idea, only showing it briefly.  I'm not sure I'd make that product specific, i.e. show it briefly when there is overlap.

I'd love to see this.

> That's a great idea, only showing it briefly.

...but always during scrolling? Eg. briefly as soon as a new item is displayed.

Created attachment 3664 [details]
demo of only displaying X of Y when scrolling

Michael - heres a demo of what I was thinking of for Input.List

If the count is requested then it is put on the top right but only while scrolling, after scrolling it hidden.  I quite like it especially for Boom - also prefer X / Y rather than X Of Y.

Personal view is that this is better than only doing it for long text as it makes the screen look odd if there just enough text to make them overlap but not enough to fill the screen

I really like the appearing/disappearing indicator.  Great idea!

I don't think I'm ready to move to "1/8" from "1 of 8" unless the language makes it very long.

I did notice that some screens (Favorites, XMLBrowser) didn't get updated with this patch, but as you say, it's a demo.

ok - I'll do another patch with X of Y

I've only done input.list at the moment, input.choice is used for those other modes - this puts the count on if {count} appears in the header text - looking at that now, but may need to change the api slightly.

Created attachment 3665 [details]
Updated patch covering input choice

Dean - try this one - should do input.choice too

Still only a demo as I am relying on code from SB2 class players and have not tried on older displays yet.  However lets get it looking correct first.

Input.Choice should probably move to the Input.List format for defining when count is used as at present I'm looking for a token in the header and then applying it to the overlay.

First I've heard of this, but I have to say I don't like it.  Not to say it won't grow on me though.  It's a bit distracting and takes your eyes off the more important menu text.

I heard a request from andy that the overlay stay up longer.  I agree, if you scroll slowly it flickers.

I also noticed that the now playing mode isn't using the new mechanism yet.  In that mode, I think we'll need the parens only on the current song when it's pushed up against the NOW PLAYING text.  Otherwise, keeping it on the top right as now is good.

I've increased the time it is on the screen for.  Looking for positive feedback on this as I've yet to make it work on older players so want to know we are going to keep this.

Now playing is a different mechanism - I was planning to make it work like this for the playlist (non currently playing song) display.  

For the currently playing song we can make the X of Y one of the options in the now playing selection - this means a user can remove it from boom to free up space.

I would still like to suggest we look at more icon based displays here - see example attached.   It think this gets more information on the same sized screen.

Created attachment 3673 [details]
example of using icons in now playing display

When you first push into a menu, the "1 of x" text is not displayed.  Probably should be.

I'm not opposed to having an additional Now Playing format that is icon-based as an alternative.  Two caveats: 

1.  It shouldn't be the default
2.  Let's keep the progress bar style that we have.

Of course, we have plugins for this, but it is a commonly suggested feature.

But let's open a separate bug and target it independently of this bug for that.

OK so I think this is done now except for any remaining discussion for the Now Playing display in playlist mode.  I've changed the playlist entries to put X of Y in the overlay, but we can't do this for NP as other stuff goes there.

Is anything wanted for this ?  [I was considering X of Y to be one of the options that could be selected for this display so a user could choose to remove it and see progress and time etc]

I showed this to my wife and my daughter. They both were OK with it. I asked them about how long it should be on the screen. My wife thought the duration was OK, but my daughter thought it should be on the screen just a little longer.

I don't have any recommendations on this, but I thought the feedback might be helpful if you still want to tweak this parameter.

Does OK mean its just about OK or were they happy with it?

I've tried it with it longer and it seems to linger to me.  If you want to adjust then change the time set in the timer call at the end of Slim::Display::Squeezebox2::animationComplete.

The line:
Slim::Utils::Timers::setTimer($display, Time::HiRes::time() + 1.0, \&Slim::Display::Display::update);

change the 1.0 for a larger value.

What does OK mean? Neither my wife or daughter had ever noticed the "x of y" before. So I had to point it out to them and explain what it did. My daughter (10 years old) said she just usually scrolls continuously until she found what she liked and never saw this feature.

I hope that explains what "OK" means in this context. Definitely not the most knowledgeable SB users. But my daughter's a big SB user, so I hope this feedback helps.

Note: see Bug 8898, which is essentially a request to stop hiding X_OF_Y. :-)

*** Bug 8898 has been marked as a duplicate of this bug. ***

I find the X of Y info useful, and its quick disappearance is a little unsettling. It almost feels like a screensaver is kicking in -- my first reaction was "Oh, no, what's happening?" The player UI only shows a single menu item at a time, so X_OF_Y is a nice, simple way to communicate the length of the current scrollable list. 

Per http://forums.slimdevices.com/showthread.php?t=49253&page=8
please add a pref to restore the "(X of Y)" indicator to the top line. 

I'm good with having an advanced setting that lets the user turn on/off the hiding.  Let's default that setting to on (i.e. hide) for boom and off for all other players.  

Ok - will look to add a pref.

Change 22209 adds a pref which defaults to always showing on all players but boom.  Can be changed from the display settings web page and menu on the player.

Note the player interface does not show the change until you leave the setting screen.

Kevin - can you comment on this feature of S:B:Settings?  (would be nice to see the change as soon as you set in the button mode.)

the settings UI only changes the pref.  If you want to see the effects of that pref, you need to also trigger whatever event relies on the pref.  The settings UI has no control over the lines function that shows the count or not, so the \&setPref call probably needs to be changed to call that PLUS trigger a refresh of the display. Also, I'm not seeing the pref in INPUT.Choice, which is what the settings UI is using. Instead, it's checking 'alwaysShowMenuCount'.  I assume it's a typo? The correct pref is in 22210, but I can't test just now.

Kevin - thanks - the typo fixes the confusion I was seeing (it worked in input list and not input choice!)

cool.  Is it also intended that the brackets be missing from the count?  I see they were stripped out in 22054.

Yes brackets were deemed not necessary as the count is moved away from other text (and they take up space)

The only place they remain is on the now playing screen - we probably need to review if they should stay here.  I favor redesigning this screen, but that would probably be an option (as per discussion earlier on this bug)

ah ok, well, guess this one is fixed?  Other redesign should probably be punted into the planned player ui rework...wherever that is.

I'm not sure whether I'm a fan of displaying the numbers in the upper right hand corner of the larger displays.  It certainly requires more work to read them vs. the old position.  That may or may not be a good thing.

Verified: 7.2-22579 r26

Large bottom line font = NO top line font
Medium bottom line font = small top line font
Small bottom line font = medium top line font

Looks good enough to ship

(In reply to comment #40)

> Looks good enough to ship

Hold on.  On the Boom I'm seeing this enumeration shown briefly _always_, not only when it overlays text.  That doesn't sound like the behavior requested above.  I think it should stay up if there's no text being overwritten.
 

see comments 10 & 11 - feel free to change the code to make it display always and see how it looks, but it looks odd to me as when you scroll up/down a list sometimes it hides and some times it doesn't.  This is counter to the usual idea of making things operate consitently to avoid supprising the user.

(In reply to comment #42)
> see comments 10 & 11 - feel free to change the code to make it display always
> and see how it looks, but it looks odd to me as when you scroll up/down a list
> sometimes it hides and some times it doesn't.

Nevermind.  I just saw the reference to the pref to always have it displayed.  That works well.

When left/right text overlays as it sometimes does when the count is displayed, is there any way to avoid displaying chopped off partial characters?  Would look better.

This bug has been fixed in the 7.3.0 release version of SqueezeCenter!

Please download the new version from http://www.slimdevices.com/su_downloads.html if you haven't already.  

If you are still experiencing this problem, feel free to reopen the bug with your new comments and we'll have another look.