Rockbox.org home
release
dev builds
extras
themes manual
wiki
device status forums
mailing lists
IRC bugs
patches
dev guide
translations



Rockbox mail archive

Subject: discussion regarding adding settings (PLEASE add your 2 cents)

discussion regarding adding settings (PLEASE add your 2 cents)

From: Jonathan Gordon <jdgordy_at_gmail.com>
Date: Mon, 27 Oct 2008 13:58:53 +1000

I think its time to have a proper discussion about adding settings
(and to a lesser extent, adding features which may not be used by the
vocal majority.) I'd like to keep the two topics separate but I don't
think it's really possible.

This is being prompted by XavieGr's email and patch (FS#9455) but I'd
rather not discuss that patch here and just keep things general
because while this is the latest patch to bring up the topic, it's
definitely not the first or last.

So what are the arguments against adding settings?
As far as I can remember, these are the only arguments which have come
up (or that I can think of).
1. bin increase
2. settings bloat (i.e we have too many settings already)
3. code maintainability
4. The majority of users won't use the setting.

1. bin increase
Well, As civil as I'd like to be, I think everyone knows my views on
this argument… Its nonsense. What's the point of the project if every
time a red delta happens everyone complains? May as well close up shop
here.

2. Settings bloat.
Yes, we have lots of settings (168 in the e200 sim) but why is this
bad? If you don't change a setting and are happy with the default then
good for you, your config.cfg will be a lot smaller than someone who
does change a lot more settings. When was a decision made to make
rockbox only for the common person? The whole point of rockbox is for
people who want to customise and use their DAP the way *they* want to,
not the way someone else wants to impose on them.

Now there is a very valid argument here that the menu is crap, and yes
that's true, but then that should be the focus of our attention. Fact
of the matter is that we use less energy arguing about it than
actually fixing it. Yes there is a wiki discussion about fixing it,
but I wonder if we should talk about splitting up the settings menu in
such a way that infrequently used settings are placed differently in
the menu (hidden if you don't want to see advanced settings maybe? Or
moved to a plugin even?)

I'm actually willing to bet that if we hid advanced settings in the
menu, most people would show them, change the setting then hide them
again to unclutter the menu.

Last point on this, at least half the bin/ram usage associated with
adding settings is in the code to add it to a menu. If some of the
less used settings were pushed out of the core there would be plenty
of bin savings to be had.

3. code maintainability
Meh, a non-argument. You can't argue that adding a setting will make
global_settings or settings_list.c any *worse* than it already is. And
I would argue that "blaa = global_settings.my_setting_value" is easier
to maintain/understand than "blaa = 15" especially if that happens in
a few places. Besides, I'd like to think that the guys who are adding
assembly to the code are smart enough to handle a struct access…

4. The majority of users won't use the setting.
Well, this is sort of the same as point 2, but I thing that should be
added is that until we add the setting AND setup a website so people
can submit their config.cfg files for statistics, we will never know
how many people use what.


I mentioned about adding features which may not be used by everyone
(particularly the loud people who the feature is obviously not
targeted at) and I think it's the same argument as above. The only
difference is its ram usage which is fair enough if it's huge (unless
it's allocated at boot time), but then remember AA uses static
buffers, as does the WPS and both of those add absolutely nothing to
the usability of the DAP, only its appearance.

So that is my argument. PLEASE reply because I really would like some
sort of consensus.

Jonathan
Received on 2008-10-27

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