Rockbox.org home
release
dev builds
extras
themes manual
wiki
device status forums
mailing lists
IRC bugs
patches
dev guide



Rockbox mail archive

Subject: Re: jdgordon: r21307 - trunk/apps

Re: jdgordon: r21307 - trunk/apps

From: Paul Louden <paulthenerd_at_gmail.com>
Date: Tue, 16 Jun 2009 13:26:54 -0500

Jonathan Gordon wrote:
> Thats an interesting idea... but how would it work with theming?
>
It's also impossible on pure mono targets anyway.

I really don't think removing the menu item would be that bad when
there's no playback to resume, personally. My original idea of "say
nothing to resume" wasn't something I expected him to immediately
implement, just a suggestion at how we could explore other possibilities
if the whole "make all splashes 3 or 4 seconds long, but make them able
to be cancelled if you know the one specific button" was mainly to solve
certain splashes being particularly annoying. Rather than redoing the
whole splash system to make it more annoying for people who don't know
about the button, address the annoying splashes and make them easier to
avoid. The two annoying ones he named were the "Cancelled" one for
settings (which seems fairly easy to avoid to me, so I didn't have any
ideas for) and "Nothing to Resume" (which also seems easy to avoid to me
- remember if your playlist ended, but I also suggested what got
committed as a basic example of providing feedback that the playlist is
empty before someone tries to resume it, instead of waiting until after).

We show or hide the recent bookmarks entry (if I recall correctly) based
on certain conditions. I don't see that showing or hiding the resume
entry will be much of a problem. Most people use the resume button
anyway, but the absence of the entry will provide a clue that people
will quickly associate.

A third sort of option could be a playlist position indicator in the
status bar. The usual [current track / total tracks] or possibly
"Filename.m3u8".

There's probably a dozen other alternatives that can be explored in this
general range of ideas, but my original point had been "we should try to
identify what problem we're solving before we apply large, broad solutions."
Received on 2009-06-16


Page was last modified "Jan 10 2012" The Rockbox Crew
aaa