|
Rockbox mail archiveSubject: 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 |