dev builds
themes manual
device status forums
mailing lists
IRC bugs
dev guide

Rockbox mail archive

Subject: Re: Buttons in Hold Mode

Re: Buttons in Hold Mode

From: Rob Purchase <>
Date: Thu, 22 Oct 2009 18:42:51 +0100

On 22/10/2009 09:49, Paul Louden wrote:
> Using the grid-based screen I was able to use my D2 in my pocket
> rather effectively. I wouldn't say "allows" so much as "enhances" or
> perhaps "provides an alternate means of."

Sure, but the grid mode is just a stop-gap until a full touch WPS is
provided by default. I'd like to see the option removed once all the
main screens have been adapted (although the API to set grid mode should
remain as a convenience to plugins). In any case trying to use a touch
screen "blind" is a rather futile exercise.

>> - Allows Rockbox to further its goal of being a full firmware
>> replacement, by implementing one of the OF's most useful features
> This is just a controls issue though. There's been a lot of control
> layouts from OFs that aren't duplicated, so I don't see this as
> particularly relevant beyond a nodding mention. It's relatively minor.

See above - without this usability is comprised, and there is no
shortage of D2 users who will back

>> Disadvantages:
>> - Potential for unintended button presses (not an issue on the D2, as
>> stated above)
> Still an issue on the D2 - while it doesn't happen to you, that
> doesn't mean they can't or won't happen.

I haven't seen a single report of a user having trouble with buttons
being pressed when they didn't expect it, hence a non-issue.

>> - People may start to expect it on other targets (but is this a
>> problem?)
> Yes, because several targets have hardware hold switches.

And another goal of Rockbox is to fully support the hardware where
appropriate - we can only act within its bounds. What is your point?

> Support and more options cruft. How much does this option *really*
> help? Is there a way to solve this problem in the existing UI without
> creating a new option and making users choose between the ability to
> hold and the ability to adjust volume easily? Let's look for
> alternatives first.

Again what is the "support" objection, rather than just stating it as fact?

How does the option help? Well, you yourself said above that hitting
buttons while on hold might not be desirable - so give users the option.

As for other options - they're rather limited within the scope of a
player with three physical buttons.

>> So, what I want to establish if there are any other objections, or
>> whether the above minor disadvantges are enough to keep a useful
>> feature out of Rockbox (and if so, why?).
> This is a somewhat misleading sentence - in the way you phrase things
> here you're attempting to establish that other objections are necessary.

No, that's not what I meant: read the words I wrote without adding your
own. I was trying to establish why/whether the existing objections are
enough to keep this out, and whether there are any others.

> Every feature that improves usability is "useful" but you've not made
> any attempt to establish how useful this feature is, just "I use it,
> and some people want it."
> Let's have a real discussion of why it's necessary or important,
> rather than trying to say "the objections against it are trivial, so
> it should go in." Even if there weren't objections, it should be
> justifiable.

Why? Where was the "necessary or important" discussion regarding custom
statusbar, DSP limiter, timestretch, USB HID and numerous other features
added recently? You can suddenly start saying new features should be
justified when it happens to be one you don't like...


Received on 2009-10-22

Page template was last modified "Tue Sep 7 00:00:02 2021" The Rockbox Crew -- Privacy Policy