|
Rockbox mail archiveSubject: Configurability; was: Re: Voice patchesConfigurability; 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 > >menus. > > 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 this: 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 Page template was last modified "Tue Sep 7 00:00:02 2021" The Rockbox Crew -- Privacy Policy |