View Full Version : Alarm icon positioning

2008-09-04, 18:27
Is there a way to reposition the "alarm active/alarm snoozing" icon? This may just be me needing to change my preferences, but right now I have my Boom set to display date and time when off. I prefer it to be "WWWW, MMMM DD, YYYY" which today works out to "Thursday, September 04, 2008." The problem being that the "8" in "2008" overlaps the little bell icon for the alarm, making it hard to tell if it's there period, and harder to tell if it's flashing to indicate I am snoozing.

Is there a solution aside from me going to some shorter date format? Or waiting for Friday, when the text is shorter? ;-)


2008-09-05, 01:22
> Is there a way to reposition the "alarm active/alarm snoozing" icon?

No there isn't. But believe me: it has been topic of _many_ discussions. We came to the conclusion that the user should simply be reasonable enough not to chose a format which will overflow.

> Is there a solution aside from me going to some shorter date format? Or
> waiting for Friday, when the text is shorter? ;-)

Obviously our above assumption was wrong :-).



2008-09-05, 01:32
The discussion was even more general than "alarm" - the Boom display will chop off years of ordinary time display in certain circumstances.

See http://bugs.slimdevices.com/show_bug.cgi?id=8695

The example screen captures attached to the bug report came from SoftSqueeze which truncates more than a real Boom so the issue looks worse than reality.

2008-09-05, 06:57
Yes, I figured this had been covered. And, yes - while I could select a different date and time format (and will, for the time being)...Shouldn't this still be handled? We're basically saying there are options available to the user which "break" other functionality.

2008-09-05, 07:26
I think the conclusion is that Boom has a smaller display so user should make allowance for that. On a small display do you really need "September" vs "Sept" and it is a per player settings so your other SB player can use full size.

The problem only manifests itself on a few days per year and it doesn't break the real functionality of the SB (i.e playing audio).

It would be possible to create a narrower font (even say for numbers) and those affected users could select the narrower font but it would be less readable.

2008-09-05, 10:46
You're right, it does only happen a few days per year, and yes, I can figure out what day it is when the display says "Thu, Sep 04, 2008" as opposed to "Thursday, September 04, 2008," but I like the full format...else I wouldn't have noticed the bug.

Now, yes, it's super trivial. Yes, I am completely in love with my Boom. But - I was always taught to test boundary cases when programming - this strikes as me something that just got missed in testing. I would totally have missed it myself - it just so happened that I took delivery of my Boom on the day with the most characters in the month with the most characters, and began fiddling wildly with it to explore it's capabilities.

I'm also not sure I agree with the user having to make allowances for a device's capabilities. I'm not advocating some kind of safeguard that keeps my from turning up my music too loud, becuase obviously a user should know s/he could damage a device by blaring it at full volume, and that's something a user should be responsible for managing - just that when the display is totally programable, why not program it so it works in all cases, and not just most. Then I don't have to worry about it.

I'm not hating on the developers, if it's coming off that way. Just pointing out a bug so it can be fixed. Everyone involved with by SB3, my Boom, and SqueezeCenter have done an absolutely over the moon job with the product development - I rave and rave and rave to everyone I see about how completely awesome each piece is.

Edit: No - wait...Wednesday is longer. So Wednesdays and Thursdays in September, and then Wednesdays in February, November, and December will exhibit this problem, as I think the WWWW, MMMM DD, YYYY string only needs to be one character shorter to not overlap the bell icon. So I can't argue it's not a rare occurrence.

2008-09-05, 11:14
Do you really need to be reminded what year it is?

2008-09-05, 11:59
No, I really don't. It's personal preference (which I will have to change, apparently). It sounds like it's already tracked as a bug anyway.

2008-09-05, 12:25
Sorry... I couldn't resist. But it probably should be fixed if it looks bad.

PS: I can relate to your sig tagline. Nice to know I'm not the only one.

2008-09-05, 12:52
Yes...someday...someday the stereo will be sig-worthy. But I had to go buy a Boom, which put a dent in my "bigger speakers" fund.

2008-09-05, 14:02
On Fri, Sep 5, 2008 at 12:52 PM, androidtopp <
androidtopp.3fa5pn1220644503 (AT) no-mx (DOT) forums.slimdevices.com> wrote:

> Yes...someday...someday the stereo will be sig-worthy. But I had to go
> buy a Boom, which put a dent in my "bigger speakers" fund.
Not to worry. No need for bigger speakers if you have the Boom ;-)

2008-09-15, 10:11
OK - I got to thinking about this. Yes, I'm an idiot, but "Mon, Sep 15, 2008" doesn't have the same graceful feel as "Monday, September 15, 2008"

If there's not enough room on the display for all that junk, I could cut out the year...as MC pointed out, that's the one thing I'm almost always certain of. And, eliminating those 4 characters would prevent the alarm overlap issue.

I see in one of the source files (can't remebber the name now)for SC that there's a list of date formats. I tried adding one in the format I'm aiming for (WWWW, MMMM DD), but it didn't show up in the date configuration drop down, even after restarting the SC service. In fact - nothing happened. I figured editing it would either break it or have some other non-desirable outcome...but the software seems completely unphased. Sorry, I can't post exactly what I added right this instant - can't get to the home computer to check my changes.

So, is what I'm trying to do impossible/unsupported/silly? Anyone with experience making small modifications to the code?


2008-09-15, 10:18
I think someone just needs to make an enhancement request for a date format that excludes the year. I was recently looking for a time format that excluded the AM/PM and saw that there was already an enhancement request and a fix in 7.2.1.