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

Rockbox mail archive

Subject: Re: committal of patch

Re: committal of patch

From: Paul Louden <>
Date: Sun, 14 Jun 2009 10:12:01 -0500

Antony Stone wrote:
> Is the problem with "yet another setting" the storage space required to
> remember it, or the menu complexity required to provide access to it?
The memory involved should be trivial compared to any code implementing
the new feature. "Settings bloat" generally refers to the case of the
Rockbox menus becoming a hassle to navigate, or ever more overwhelming
for the new user.

I think though that this feature should have its own setting. It's
navigational, and shouldn't be associated with the track skip beep.
They're simply two very different notifications, they just happen to
both beep as their means of notifying you. That being said, I'm not
really sure I understand why an end-of-list beep is necessary. If you're
looking at the screen, it obviously isn't. If you're managing blind and
using voice, you'll hear the start of the voice entry for the last thing
in the list at the same time you would hear a beep if it were enabled.

Given that you navigate lists to get to a specific option, if you're
scrolling you'll need to listen to the voiced entries anyway to find the
option you want. When do you need to know you're at the bottom, without
needing to know what any of the list entries are, including the last one?

As a note: when navigating with voice, can't you already tell you're on
the last entry by holding "down" until it stops changing entries? Since
moving to the next entry should interrupt the voicing, as soon as it
stops cutting off voicing and starts to read the whole entry, you'll
know you're at the last one.

What exactly is the intended purpose of this feature?
Received on 2009-06-14

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