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



Rockbox mail archive

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

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

From: Mark Ganson <mwganson_at_hotmail.com>
Date: Mon, 27 Oct 2008 15:42:02 +0000

For what it's worth, and probably not very much, I think a settings plugin is a great idea if that will reduce binsize and free up buffer memory. A settings plugin could be used for all settings options, not just the less commonly used ones. Selecting Settings in the main menu brings up the settings plugin. Users won't even notice the difference because the UI would remain the same.

In my view, the more features and settings options, the better -- up to the point where you begin trading bin/ram for that feature, whereupon the discussion needs to be whether the feature is worth the cost. Even then, if the new feature only costs bin/ram for those users who actually use that feature, then adding the feature becomes a no-brainer. I like Jonathan's test for a new feature: the burden should be upon those who don't want it to show why it shouldn't be added rather than upon the ones who want it to justify why it should be added.

I'm not in favor of hiding advanced settings. That's just adding more complexity to the code by having a setting related to the settings. It's like having a meeting to discuss another meeting.

> Date: Mon, 27 Oct 2008 13:58:53 +1000
> From: jdgordy_at_gmail.com
> To: rockbox-dev_at_cool.haxx.se
> Subject: discussion regarding adding settings (PLEASE add your 2 cents)
>
> 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

_________________________________________________________________
When your life is on the go—take your life with you.
http://clk.atdmt.com/MRT/go/115298558/direct/01/
Received on 2008-10-27


Page was last modified "Jan 10 2012" The Rockbox Crew
aaa