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: Paul Louden <>
Date: Thu, 22 Oct 2009 12:54:59 -0500

Rob Purchase wrote:
> 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.
How is using the touch screen blind any different than using the iPod
wheel blind? Neither have any physical feedback to let you know
orientation other than the orientation of the player, yet people manage
play, pause, next and previous just fine.

The grid mode absolutely should not be removed - it's the ONLY way to
allow full use of the player blind.

>> 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
It's compromised if you arbitrarily remove a mode that should not be
removed, sure. That's a silly argument though - "we should remove a mode
that is necessary for some users to even be able to use the player at
all, and replace it with something far less functional that also has
other reasons to be objected to."

>> 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.
"Nobody's reported it, so it's a non issue" doesn't hold water. It still
can happen or the hold switch wouldn't exist on it or other players.

>>> - 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?
My point was simply that there are players where this kind of
functionality cannot exist.

> 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?
"Why does my hold switch not work in Rockbox?" For most normal users,
especially those not used to the D2 software in advance, the expectation
is that a hold switch prevents buttons from working. It's likely to
cause some confusion or bug reports unless it's disabled by default.

Why even add this in when the option of having the grid-based mode is
_far_ superior both in added functionality, and in not creating new

> 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.
But the option isn't _worth_ it. I didn't deny it would help, but one
goal is to not arbitrarily add new options, as the number is quite high

> 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.
Yes, but you've already also established that you feel the existing
objections aren't enough. You know why the objections above exist, so
the "if so, why?" is disingenuous because we'll just be repeating
reasons to you that you already know, and aren't going to agree with. It
establishes then a necessity that new reasons be offered to you, because
you've already made up your mind about the existing ones.

>> 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.
> 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."
> 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...
There's no alternate way to have a custom status bar, DSP limiter, USB
HID, etc. But there is an alternate way to change the volume or skip
tracks while the player's in your pocket. A way already coded. A way
already IN Rockbox. And one that allows you to skip tracks, adjust
volume, stop and resume playback, navigate menus, and perform playlist
editing (among other things) while the player's in your pocket, or being
held but not looked at (biking, jogging, in a car).

This option is basically a far inferior one to an existing feature that
simply provides some familiarity with the original firmware.

What we're discussing here isn't simply "should this go on" but "should
we duplicate existing functionality in inferior ways to match the OF"
and, if you're advocating removing the grid mode, "can we justify
removing blind usability features just because we personally wouldn't
use them and think an inferior alternative is good enough?"
Received on 2009-10-22

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