Rockbox mail archiveSubject: Configurability; was: Re: Voice patches
Configurability; was: Re: Voice patches
From: Tapio Kelloniemi <spammi.helevetti_at_nbl.fi>
Date: Sun, 7 Oct 2007 11:28:21 +0300
On Sat, Oct 06, 2007 at 06:38:13PM +1000, Daniel Dalton wrote:
> On 6/10/2007 1:21 PM, Stéphane Doyon wrote:
> >Also a quick way to adjust volumes when browsing files or
> Is this sort of thing likely to be implemented into rockbox.
> I am not saying at all it is not a good idea. Personally I think it is a
> great idea but most of the devs are sighted and may think it is a waste
> of a button.
Well, everybody who doesn't use voice, will think that adding a button
for voice control is waste. IMHO there are two alternative solutions to
1. Make all buttons configurable. This is preferable and it would be
extremely useful for everybody, including sighted folks. Devs have however
decided that such a feature will not make its way to RockBox, because
it would introduce a support hell. This means that RockBox is not fund
for advanced users who demand advanced features. Of course anyone
can do their favourite remappings and recompile Rockbox, but more
advanced things such as "dead keys" cannot be implemented with one line
of code, and if all advanced users do this on their own, it is a waste
of resources. In order to make Rockbox an extensible, customisable digital
audio player firmware a change in attitudes is needed. Personally I don't
believe in this possibility.
2. Add a quick screen for voice users which is accessible in all contexts.
In this "quick screen" a voice prompt would be issued and following
key presses could be used to trigger actions (eg. change volume,
speak battery level, etc.) However, wasting a button problem remains
unless the button mappings of this screen are made configurable.
> Also I am working on a long press of rec to say the time and a short
> press to go to the radio.
This rec button has been discussed for years. I don't believe that
any patches related to this issue will be applied. (see above for configurable
button mappings which would solve this issue once and for all).
And while we are talking about wasting resources, I think that my LCD is
wasting the battery very much. I would like to disable LCD support altogether,
except of course in the boot loader, if something goes wrong. IMHO Rockbox
should be configurable and modular (both at compile time, and at run time).
I really much would like to comment out a line like the following in a header
file when compiling Rockbox:
#define LCD_SUPPORT /* LCD screen support in Rockbox core */
I hope that developers see that not all users have the same intentions
regarding their use of their DAPs. If it were possible to customize Rockbox
more at compile time, new and possible resource-greedy features could be
added, since people could enable them when compiling Rockbox and at the same
time disable some functionality which they don't use. Imagine Rockbox with
'make menuconfig' a la Linux; or imagine Linux without 'make menuconfig',
which would have been replaced by implicit 'yes | make config'.
I know that Rockbox is very different from Linux in many aspects, but the
most succesful open source and free software projects (such as emacs) have
a very versatile customisation support. This is why they have become so
popular. I'm not asking to make Rockbox suitable only for programmers, not
at all, configuration must be optional. Prebuilt binaries and sensible
defaults must be provided for nontechnical users. Achieving this is not
trivial, but it is possible, and no one loses.
This is my personal opinion which, I hope, will raise some debat.
-- TapioReceived on 2007-10-07