Re: discussion regarding adding settings (PLEASE add your 2 cents)
XavierGr wrote: And, as a point of interest, we're already using ~20-25% of the available RAM on the Cowon Coldfire-based players as it stands, binsize is not only important to the Archos players. We're also looking at players that only have 384kb of RAM, which makes binsize an even more significant hurdle for those (which will probably need a specially toned down build of Rockbox anyway). **Darn tooten dude! My newX5l will soon be here and I don't want to see battery performance decreased due to excessive disk spinning. You guys rule...rocker
Re: discussion regarding adding settings (PLEASE add your 2 cents)
On Wed, Oct 29, 2008 at 12:58 PM, Paul Louden [EMAIL PROTECTED] wrote: This again is a false comparison. The WWW doesn't have resource restrictions in the same manner as Rockbox. Assume the internet became slower for everyone, the instant any website was put up. Were this the case there would immediately be a concern on the value of having more information available versus the ability for people to access this information in a reasonable time frame. Assuming there were a controlling authority, any website put up would be looked at in terms of how many people will this help versus how much current, and potentially future, cost will this have to users who will, and especially who won't, use this feature. I'm sorry you feel that I made a false comparison - sounds a bit oxymoronic to me. Anyway, we seem to agree that the issue is: how much current, and potentially future, cost will [the inclusion of a feature] have to users?.
Re: discussion regarding adding settings (PLEASE add your 2 cents)
Paul Louden wrote: That means less useful features should be considered critically even if they have small binsize costs, just because they're useful to only an exceptionally small group. They're a dilution of the total usefulness density. Let me chime in with my $0.02. I think that the binsize isn't *that* important for the battery life. If a feature adds 10Kbytes to the binary, it means 10Kbytes less buffering memory. That is hardly measurable at all, only a few frames of an MP3 file. Yes, the binary size would matter if Rockbox would grow out of control, but we all know that won't happen. I also tend to get the feeling that the binary size card gets played a little too often. Especially when it comes to GUI features, or eye candy. Linus
Re: discussion regarding adding settings (PLEASE add your 2 cents)
Linus Nielsen Feltzing wrote: Let me chime in with my $0.02. I think that the binsize isn't *that* important for the battery life. If a feature adds 10Kbytes to the binary, it means 10Kbytes less buffering memory. That is hardly measurable at all, only a few frames of an MP3 file. Remember that even now we're looking at at least one upcoming target with a total 2.3 MB of RAM. Even assuming we dropped the plugin buffer, and read audio directly from flash, this presents a real binary constraint while preserving speech support, even if we ignored a desire to continue supporting the Archos targets. I'd also like to challenge anyone here to find three features that were actually rejected with binary size being the cause. I'm sure many people have spoken up saying I don't think it's worth the binary cost but I'm sure no feature's ever been reverted for it, and I doubt many, if any, flyspray tasks have been closed with that as the sole (or deciding) cause.
Re: discussion regarding adding settings (PLEASE add your 2 cents)
On Wed, 29 Oct 2008, Paul Louden wrote: I'd also like to challenge anyone here to find three features that were actually rejected with binary size being the cause. And I also would like to remind you all that: it doesn't matter Each feature is taken on case by case so just shouting to the general crowd that we do X too often is not a very good way to make the crowd do less X. This is also true if X is 'call the binsize card too often'. Thus, it doesn't matter if we agree on this X or not... -- / daniel.haxx.se
Re: discussion regarding adding settings (PLEASE add your 2 cents)
On Wed, Oct 29, 2008 at 6:35 PM, Daniel Stenberg [EMAIL PROTECTED] wrote: This is also true if X is 'call the binsize card too often'. Thus, it doesn't matter if we agree on this X or not... I agree, but I think the goal of this thread is to clarify for some people exactly how important binary size is, by coming to a compromise, a consensus, so as to avoid having the same argument repeatedly on a case by case basis. One way to reach this compromise is with a formal set of guidelines, which take into account the figures and the situation, e.g. the 2.3 MB RAM target that Paul points out. I personally do not know enough to draft these guidelines, but I'm sure many of you are. Is it possible to quantify the effects of binsize?
Re: discussion regarding adding settings (PLEASE add your 2 cents)
Roy Wallace wrote: I agree, but I think the goal of this thread is to clarify for some people exactly how important binary size is, by coming to a compromise, a consensus, so as to avoid having the same argument repeatedly on a case by case basis. Since the original message in this wasn't explicitly, or solely, about binsize, I don't think this is the point at all. One way to reach this compromise is with a formal set of guidelines, which take into account the figures and the situation, e.g. the 2.3 MB RAM target that Paul points out. I personally do not know enough to draft these guidelines, but I'm sure many of you are. Is it possible to quantify the effects of binsize? Not really, since it varies on target-to-target basis. For example, binsize is exceedingly important on any target where we could potentially run out of RAM entirely. Binsize bears almost no value at all on 64MB targets where we could probably grow the core binary to 4MB and see only a barely measurable loss in battery life. But it has to be discussed on a case-by-case basis, for the very reason that not every feature uses binsize well. For example, a two features may each use 5k of binsize. One helps a small group of users, but is actually necessary for that small group of users to be able to use Rockbox effectively at all. The other one makes life very slightly better for all users. Clearly each one should be discussed independently as their value, and why they are valuable, is debatable despite their equal binsize costs. There is no objective way to value how much it helps those it helps and we have no metric to by which to determine how many it will help so we can only go on our own opinions of the value of the feature, to us and our own guesses as to the user base. Even if we set a 2.3MB maximum, that wouldn't allow us to say okay, no debating features as long as someone wants them, until we reach the cap. Instead we'd be saying Look, when we reach 2.3MB used RAM, we can't add any more features at all without removing features. What we need to do, now, is look at this feature and say 'do we think it's likely we'd be willing to remove it in the future?' and if the answer to that is yes, we may as well just go ahead and scratch it now, because we should strive to get features that really increase the overall value of the software, rather than 'filler' features that allow it to do more, but we're readily willing to cut later.
Re: discussion regarding adding settings (PLEASE add your 2 cents)
On Mon, 27 Oct 2008, Jonathan Gordon wrote: I think its time to have a proper discussion about adding settings Interesting discussion. Since I was gone during the better part of it, I'll just add my sparks to the flames: o I think referring to or assuming that discussions on IRC are good to conclude consensus or agreements from is bad. If a discussion, idea or feature truly is to be discussed it NEEDS to be taken to this very mailing list. Not even the patch tracker is good enough to attract the necessary attention. o No matter how much some people blame some other people for being feature-phobic it doesn't help even a tiny bit. What we would rather need is ideas or suggestions on how to work on these issues so that the apply-everything group and the never-increase-binsize group can get together and still make Rockbox develop. I could very well imagine that we use the Steering Board for voting on the hardest issues to avoid deadlocks. o We MUST still take each issue in a case-by-case approach and weigh in the added feature, options, coolness, beauty against the bloat, binsize, code complexity, support amount etc. Even if we would change in how much binsize we want, we still need a case-by-case decision process. And we're still hundreds of hackers, all with our own personal preferences to what way we'd like Rockbox to evolve. -- / daniel.haxx.se
Re: discussion regarding adding settings (PLEASE add your 2 cents)
On Mon, Oct 27, 2008, Paul Louden wrote: XavierGr wrote: Sorry but my memory doesn't help me much. Which are these 384kb of RAM targets? (I hope that you don't mean the iFP). Sansa Clip. The iFP has 1MB of RAM. The Sansa Clip has 2MB of RAM. I think an audio player (especially if it has to support more than MP3) can hardly fit with less than 1MB of RAM. It must be simpler for manufacturers to spend their money on hardware rather than on software optimizations. -- Rafaël Carré
Re: discussion regarding adding settings (PLEASE add your 2 cents)
Jonathan Gordon schrieb: none of these have a working patch yet, and yes there will be argument if/when they ever are ready. Depends on you define as working. They all have a working patch, but if their committability is another question (and I quite like how my custom list patch works). I pretty much agree with XavierGr in this discussion. Devs tend to evaluate new features only on their own using habbits. More then often binsize seems (to me) just to be brought up as a reason since it's the standard reason and sounds very much better than I won't use the feature, so it won't get in, especially not if I'd have to look at an option more in the setting. I don't say binsize isn't a valid reason. But it's kinda stressed very much lately, even for quite small additions. In fact, it helps stalling the developement. Why should one contribute if he doesn't have any hope to get behind the binsize wall. And the more features are rejected (or just rotting further) for binsize reasons the higher the wall seems to be. I do however say that we should evaluate settings before they get in. Unlike to the features (I like new features very much) I'm very sensitive to settings bloat. I'm really in favor of picking sane defaults most people can live with (this goes for FS#9455 as well). And with sane defaults, new features one doesn't want to use are not noticable if unwanted, i.e. let the user focus on the features he likes while being perfectly able to ignore the ones he doesn't like. We then could possibly just have a features setting menu, where you can chose from several features to be enabled or disabled. This way, unused features could free most of the RAM they waste reducing the ram usage impact. And once you have set those features, you've hardly visit the feature setting again and doesn't have to fea the settings bloat.
Re: discussion regarding adding settings (PLEASE add your 2 cents)
Thomas Martitz wrote: More then often binsize seems (to me) just to be brought up as a reason since it's the standard reason and sounds very much better than I won't use the feature, so it won't get in, especially not if I'd have to look at an option more in the setting. This sounds to me an awful lot like you saying I won't use the feature, so it's not important to me about binsize. Just because you don't see it as important as other people, you're suggesting they're hiding behind it and inflating its value to themselves. Please, for the sake of this discussion, let's assume people are being honest about their reasons for objecting to things, rather than saying People are lying about why they're against the idea and claiming it's binsize rather than them just not planning to use it. If we go around accusing people of being liars we'll never get anywhere, because nobody's statements would mean anything, all of them potentially being such lies. It doesn't serve the community or this discussion to assume dishonesty in advance, and without any proof other than your personal feelings on the matter.
Re: discussion regarding adding settings (PLEASE add your 2 cents)
On Tue, Oct 28, 2008 at 6:40 PM, Thomas Martitz [EMAIL PROTECTED] wrote: I pretty much agree with XavierGr in this discussion. Devs tend to evaluate new features only on their own using habbits. More then often binsize seems and people doing patches aren't doing them based on their habits? Do users judging patches don't do this based on their taste and possibly usage habits from other areas? Isn't in reality anyone kinda bound by its habits? I don't say binsize isn't a valid reason. But it's kinda stressed very much Maybe it's stressed much lately. But as already has been said, Rockbox is much more feature complete than it was like two years ago, and we need to decide how much bells and whistles we really want and what (and especially how much space) we're willing to sacrifice for this. I haven't seen much of a discussion about this here though. We then could possibly just have a features setting menu, where you can chose from several features to be enabled or disabled. This way, unused features could free most of the RAM they waste reducing the ram usage Rockbox uses almost exclusively static buffers. How should disabling features change the required RAM? Features that can free memory if unused already do this (at the cost of requiring a reboot after changing). Perhaps there are settings that don't do this yet but could easily be adapted. Of course it needs to get decided if the possible issues such a change might bring up is worth it. Still, for most cases this is not possible. Otherwise we would need to make Rockbox use real dynamic memory, and this is something that is definitely not wanted. - Dominik
Re: discussion regarding adding settings (PLEASE add your 2 cents)
Dominik Riebeling wrote: I don't say binsize isn't a valid reason. But it's kinda stressed very much Maybe it's stressed much lately. But as already has been said, Rockbox is much more feature complete than it was like two years ago, and we need to decide how much bells and whistles we really want and what (and especially how much space) we're willing to sacrifice for this. I haven't seen much of a discussion about this here though. Just a small followup on this point: Rockbox is also bigger than it's ever been. I think it should be obvious that binsize will become more and more of a concern, the larger Rockbox grows.
Re: discussion regarding adding settings (PLEASE add your 2 cents)
On Tue, Oct 28, 2008 at 3:15 AM, Jonathan Gordon [EMAIL PROTECTED] wrote: We have a very high level of patch rot which is the same thing (some but why do we have this high level of patch rot? Because all patches in the tracker are crap or mediocre features? I don't think so. From my impression the main problem with patches rotting is that (a) there are quite some patches that aren't good enough to get included and the author isn't willing to work for inclusion. We should consider closing such tasks (yep, that's rejecting them too. But one needs to separate between rejected because author didn't work on getting it ready and nobody else picked it up and rejected because it's unwanted for whatever reason). (b) It also seems (at least I kinda have the impression) that quite a lot of devs like it better working on their own stuff instead of checking the tracker and picking up existing patches. This doesn't surprise me at all and kinda goes back to (a) as this usually means the one picking up a patch needs to get it into shape -- I haven't seen much patches that got in unchanged (except ones done by devs). Of course there is also (c) mediocre features that are likely to be cause of a larger discussion. It doesn't seem there is much will upon devs to adopt such a patch and actually start a discussion about it. Heck, I haven't seen actual *discussions* about *patches* on this list! There are some general directions we do agree about without taking it to this list separately as those are big issues that have been addressed on IRC several times (like: we do want multifont). But those are not the problematic issues, especially as you already said as there are currently no patches about those so no need to discuss them in detail (yet). Besides, if there are objections in IRC after a commit this pretty much smells like the actual pre-commit discussion wasn't done at all. Arguing around with the people that are currently around is nice, but (as I already said) due to timezone and RL issues you will always cut those people that don't have time *the moment the debate is going on*, not giving those people a change to raise their voice. Are you really surprised if they do afterwards (as they hadn't a real chance before the commit)? - Dominik
Re: discussion regarding adding settings (PLEASE add your 2 cents)
On Tue, Oct 28, 2008 at 3:01 AM, alex wallis [EMAIL PROTECTED] wrote: Sorry but I really have to disagree with you on this one, I wouldn't describe study mode or whatever it has been renamed to as mediocre or a useless feature. There will always be people that call a feature you consider essential as useless. The main problem with track skip (or study mode, as it was confusingly called initially) is that there was *no* previous discussion, *not even on IRC* -- something that was called drive-by-commit earlier. If there had been a discussion before the commit I bet most devs would have agreed upon adding the feature after bringing it into shape -- i.e. after cleaning up the naming and usage mess it had been initially. In such a discussion you would still have found someone disliking the feature though ... - Dominik
Re: discussion regarding adding settings (PLEASE add your 2 cents)
Paul Louden schrieb: It doesn't serve the community or this discussion to assume dishonesty in advance, and without any proof other than your personal feelings on the matter. Sorry if it sounded like that. I didn't wan to say you lie at all about binsize. And I wouldn't think you're not honest. It's just that I sometimes get the feeling that the binsize response is exaggerated some times on particular discussions on propsed features/settings. Exaggerated by the means that one would agree to sacrify some (k)bytes it if the feature would fit his needs and habbits, but not if one doesn't intend to use the feature (and then rejected for binsize reasons). Don't get me wrong. Binsize (and Ram usage even more imho) is very important and you should always take it into account before committing something, but the more the binsize is used as a rejection reason, the less believable it sounds at times.
Re: discussion regarding adding settings (PLEASE add your 2 cents)
Thomas Martitz wrote: Don't get me wrong. Binsize (and Ram usage even more imho) is very important and you should always take it into account before committing something, but the more the binsize is used as a rejection reason, the less believable it sounds at times. Well, which is it. Do you believe we're exaggerating (which is a form of lying, since we're being untruthful about its actual value to us) or do you believe it's your own perception of the believability that's off? Binsize affects all users. Tiny features that do very little affect a very select group. I think it's perfectly reasonable for someone to say in my opinion this feature isn't worth the binsize if they honestly think that the number of users it will benefit is outweighed by the overall increase in Rockbox size. The goal should be to strive for a maximum density of usefulness for any given size we reach. That means less useful features should be considered critically even if they have small binsize costs, just because they're useful to only an exceptionally small group. They're a dilution of the total usefulness density.
Re: discussion regarding adding settings (PLEASE add your 2 cents)
2008/10/27 Paul Louden [EMAIL PROTECTED]: Jonathan Gordon wrote: And you've heard dozens of times it's not *just* bin increase that's a problem, but whether a feature's bin increase is worth the functionality it adds. There's a finite limit on how much can and should be added (though we've not set a target maximum binsize there's lowmem targets already showing up anyway) if every feature that shows up is added, we're eventually going to have a binary that nearly everyone will agree is too big, and have to decide if we want to remove existing features. Better to keep mediocre features out in the first place, rather than having to remove features later. bin size is the single biggest objection always. Sure there will always be the people that feel a feature isnt worth the addition, and there is people who feel it is.. why is it ALWAYS the first group who win? worrying about low mem targets is silly. We already have a mechanism to disable features if they just wont fit, and considering there is 5 (6?) targets which are considered lowmem, and 20+ which are not, why should it be harder for the vast majority to have features they want? the answer to both groups is to build your own version. Its easier to keep a #if BLAA disabling patch in sync than a feature addition patch, and more people would be using the 2nd. As for mediocre features... of course they are the only ones being argued. Amazing features go in once every blue moon (going by MajorChanges, I can count 5 which would be considered for this group in the last 12 months). Shit features are usually rejected without any objection. Mediocre ones are the only ones where there is any contention... But if everyone is happy with adding a feature every 2 months, well There's a difference between having a powerful set of options and having the ability to configure everything you could imagine wanting to configure, plus some. Tomato, tomato... a setting you consider excessive I consider required, and vice versa. 3. code maintainability It's not usually about the setting itself, but whatever functional code it activates. Many suggested settings where this is objected are things like additional playback modes, etc, where there is a real maintainability problem. I'd be surprised if anyone's objecting to the maintainability of the struct itself. no no, I'm talking about where the actual setting is the reason for this argument. I'm not talking about a setting which causes maintenance issues in code which has few people are activly looking after (like playback) But we can know how many people in the past have requested such a setting, or felt the lack of that setting is a legitimate problem. Again, that only shows people who have the idea and care enough to ask for it (or happen to ask in a place where it gets seen), that doesn't give any indication to how many would use the setting once it was in place. and we need to make sure ever feature tries to use as little as possible, Which many of the vocal objectors deem to be 0. and ever feature that does get in is one we valuable enough that it we won't be considering removing it later for something else. That, generally, means a feature needs to do something that can't be achieved another way. who is to say another way wont be worse? Would a version which is written in assembly and uses half the bin/ram size be better than a C version which anyone can maintain be better? When there are more than one legitimate way to do something, and someone provides a patch doing it one way, why should it be rejected by someone who isn't going to put in the effort to do it the other way? For example, there's a legitimate argument that we could just compromise on the spacing value rather than making it accept a configurable string. Actually no, A simple strcat would be about as simple as it could be. strcat()-ing a static string is just as bad/wasteful as strcat()-ing a user string. The adding of the setting is meaningless when it comes to the delta. Whether you agree that that's an acceptable way or not, it would mean a lesser bin increase, no added menu option, and no setting someone will debate removing later if we do run into binsize maximums. Now, at some point a decision needs to be made about every feature, but the idea that every single one should at least be challenged and justified shouldn't be thrown out. Challenged? OK, justified? No, I don't think so. Unless you loosen your definition of justify to include the sentence I and others want it, we have put in the effort, it conforms to code standards and yes, I believe this will benefit the project. I don't want to get personal, but 80+ people have been given the privilege/right to change the code as they see fit, sure there is a level of trust going both ways that it wont be abused and that commits will benefit the community, but really, there has never been discussion about changing the authoritative structure to
Re: discussion regarding adding settings (PLEASE add your 2 cents)
Hi Jonathan, 1. bin increase We're obviously going to have to agree to disagree here. You seem to think that a 32MB buffer is lots of memory; I think of it as the most important resource we have to keep battery life up. I don't know which device/setup you use normally, but perhaps it's because I use a HDD player, not a flash one? And I run off battery 90% of the time. And I've seen the buffer size drop by about 3MB in the past 2 years... [ Maybe mediocre features should only be added to flash players... ;-) ] 2. settings bloat (i.e we have too many settings already) Personally, I have no objection here (aside from binsize) - however, I do little support work on Rockbox. At my day job, we know well that every added option (potentially) gives another dimension to the test matrix. But I guess it's sensible to tell people with problems to reset their settings anyway, hence my position. I don't like the simple/advanced menus option; if a setting is worth having, it's worth putting in the correct place and won't be an annoyance per se. I do think that every setting should be accessible from the menus (where reasonable). If a feature is so unwanted or mediocre that it's implemented as a second-class citizen then I'd question its inclusion at all. 3. code maintainability This really shouldn't be a problem at all. The code we've got needs to be more modular, and I'd hope that as features go in (and people work on the code), the structure would naturally improve. Maybe I'm being optimistic again! 4. The majority of users won't use the setting. No argument for or against here - we don't have any way to measure how many users use a setting, heck we don't really know how many users there are. Of course, as Paul pointed out, later removal of a feature is likely to result in a response... Ultimately, I don't think that a general statement can be made here - it needs to be considered on a feature-by-feature basis. But IMHO the focus of the project should be more on stability, reliability and usability/consistency, not just on how many features we can pack in. pondlife
Re: discussion regarding adding settings (PLEASE add your 2 cents)
On Mon, Oct 27, 2008 at 4:58 AM, Jonathan Gordon [EMAIL PROTECTED] wrote: 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. The more settings we add the more difficult it is going to be to make the menu easy to navigate and to find your way in. So while i agree that a lot can be done by improving menu structure adding more settings invariably makes the settings menu worse IMHO. One common complaint from new users is exactly that this settings jungle is hard to navigate so i feel this is an argument against adding more settings. That said i don't think we can stop adding _any_ settings but we need to seriously consider if the setting is useful. I do personally change about 10 settings from the default but i don't think everything I don't use should be dropped but what if we get a (good) patch adding a setting maybe only the patch author will use, should we include it in svn? I'm with pondlife on the advanced settings menu btw, hiding stuff just makes the whole issue worse IMHO. Nils
Re: discussion regarding adding settings (PLEASE add your 2 cents)
2008/10/27 Nils [EMAIL PROTECTED]: I'm with pondlife on the advanced settings menu btw, hiding stuff just makes the whole issue worse IMHO. I didn't say it was a good idea... its just one (of hopefully many) idea.
Re: discussion regarding adding settings (PLEASE add your 2 cents)
Hi everybody, in general I agree to Jonathan, I personally really like to configure everything what's possible ;-) BUT: I usually only do it until I'm happy with the settings; from then on I only change a few ones. So we could consider about having an external tool (either a plugin or even only on PC) to configure _everything_ and to keep only the common settings in the normal menu structure. The problem here is to define which settings are common and which are only seldom used.. 4. The majority of users won't use the setting. I like your idea on letting the user upload their configurations and to create a statistic on it. With this input the default settings could be tuned and therefore keep the common config.cfg as empty as possible - but this wouldn't help to define which settings will be changed often and which only once... ... my two cents! with regards, Matthias (aka Massa)
Re: discussion regarding adding settings (PLEASE add your 2 cents)
2008/10/27 pondlife [EMAIL PROTECTED]: Hi Jonathan, 1. bin increase We're obviously going to have to agree to disagree here. You seem to think that a 32MB buffer is lots of memory; I think of it as the most important resource we have to keep battery life up. I don't know which device/setup you use normally, but perhaps it's because I use a HDD player, not a flash one? And I run off battery 90% of the time. And I've seen the buffer size drop by about 3MB in the past 2 years... [ Maybe mediocre features should only be added to flash players... ;-) ] gigabeast and e200 are my main players atm. and even if they were only added for flash targets that would be fine for me, they could easily be added in custom builds with little work 2. settings bloat (i.e we have too many settings already) Personally, I have no objection here (aside from binsize) - however, I do little support work on Rockbox. At my day job, we know well that every added option (potentially) gives another dimension to the test matrix. But I guess it's sensible to tell people with problems to reset their settings anyway, hence my position. I don't like the simple/advanced menus option; if a setting is worth having, it's worth putting in the correct place and won't be an annoyance per se. I do think that every setting should be accessible from the menus (where reasonable). If a feature is so unwanted or mediocre that it's implemented as a second-class citizen then I'd question its inclusion at all. off the top of my head, settings which should stay but dont need to be so high up are things like directory/playlist limits, show the title in the browser, disk and battery options, most of the display options... bassically anything which are set once options Ultimately, I don't think that a general statement can be made here - it needs to be considered on a feature-by-feature basis. But IMHO the focus of the project should be more on stability, reliability and usability/consistency, not just on how many features we can pack in. I'm not asking for a add everything or add nothing option, I'm asking for more flexibility so it turn from implicit prove why something should go in to convince me something shouldn't, and usability is all about features...
Re: discussion regarding adding settings (PLEASE add your 2 cents)
2008/10/27 Matthias Mohr [EMAIL PROTECTED]: Hi everybody, in general I agree to Jonathan, I personally really like to configure everything what's possible ;-) BUT: I usually only do it until I'm happy with the settings; from then on I only change a few ones. So we could consider about having an external tool (either a plugin or even only on PC) to configure _everything_ and to keep only the common settings in the normal menu structure. I'm with the people who are against having settings which are not (easily) configurable on the DAP itself. The furthest away from the core I would suggest is as a plugin.
Re: discussion regarding adding settings (PLEASE add your 2 cents)
I'm with the people who are against having settings which are not (easily) configurable on the DAP itself. The furthest away from the core I would suggest is as a plugin. Hi. I'm afraid that this will probably look like i'm complaining hear. However, again as i've said before in other posts on other topics, with your above comment, if we have settings as a plugin, we run into the good old brick wall that plugins are as yet not accessible with the speech interface. However if they were accessible with the speech interface, I would have no objection at all to settings being turned into plugins. Does anyone no what happened to that particular gsoc project? As for stripping out useless features, if we want to save bin size or just in general cut down on compile time, why don't we strip out doom? I mean doom is a bit of an old game now, takes ages to compile and I seriously can't imagine a majority of people play doom on there mp3 players, and the same goes for the other emulators. I mean I can imagine people playing other games such as chess, but doom is a completely different matter.
Re: discussion regarding adding settings (PLEASE add your 2 cents)
2008/10/28 alex wallis [EMAIL PROTECTED]: I'm with the people who are against having settings which are not (easily) configurable on the DAP itself. The furthest away from the core I would suggest is as a plugin. Hi. I'm afraid that this will probably look like i'm complaining hear. However, again as i've said before in other posts on other topics, with your above comment, if we have settings as a plugin, we run into the good old brick wall that plugins are as yet not accessible with the speech interface. However if they were accessible with the speech interface, I would have no objection at all to settings being turned into plugins. which is why noone has done anything in this direction. Does anyone no what happened to that particular gsoc project? As for stripping out useless features, if we want to save bin size or just in general cut down on compile time, why don't we strip out doom? I mean doom is a bit of an old game now, takes ages to compile and I seriously can't imagine a majority of people play doom on there mp3 players, and the same goes for the other emulators. I mean I can imagine people playing other games such as chess, but doom is a completely different matter. doom adds 0 to the bin/ram problem, the only reason we have it is because its a plugin and doesnt waste any ram if its not used.
Re: discussion regarding adding settings (PLEASE add your 2 cents)
Hi Jonathan, off the top of my head, settings which should stay but dont need to be so high up are things like directory/playlist limits, show the title in the browser, disk and battery options, most of the display options... bassically anything which are set once options set once for you maybe - battery capacity and maybe time/date might be the only ones we could all agree on not changing too often, but I change some display options quite often. I'm not asking for a add everything or add nothing option, I'm asking for more flexibility so it turn from implicit prove why something should go in to convince me something shouldn't, I largely agree - but of course it's a feature-by-feature decision and ultimately depends on whether *I* think the feature is useful. usability is all about features... By usability, I primarily meant simplicity (particularly of the UI). Features might help, but I'd personally put my Rockbox time (if I ever get any) into tidying up what we have...but that's a whole other discussion! pondlife
Re: discussion regarding adding settings (PLEASE add your 2 cents)
However if they were accessible with the speech interface, I would have no objection at all to settings being turned into plugins. Does anyone no what happened to that particular gsoc project? I'm still alive :). School and interviews have been kicking my ass for the past month or so and I've had zero time for Rockbox related work. The patch on the tracker is horribly out of date too. I sent my most recent work to Daniel and Stephane but even that is not ready for commit. I'm going to try and sync the patch for some review some time this week assuming I can find time. As a nice side-note, voicing does work in plugins after applying my patch,
Re: discussion regarding adding settings (PLEASE add your 2 cents)
On Mon, Oct 27, 2008 at 2:27 PM, alex wallis [EMAIL PROTECTED] wrote: Hi. I'm afraid that this will probably look like i'm complaining hear. However, again as i've said before in other posts on other topics, with your above comment, if we have settings as a plugin, we run into the good old brick wall that plugins are as yet not accessible with the speech interface. However if they were accessible with the speech interface, I would have no objection at all to settings being turned into plugins. I think that almost all settings are mostly set once. They could be loaded from an extra config file (user editable with comments explaining possible values for every setting) which is also editable through a settings plugin. The main menu then has mostly on/off settings to enable features. This has the advantage that adding configurability doesn't add to binsize, the main menu is not cluttered, a disk spin up isn't needed very ofthen, changing settings on target is possible with a plugin and if you want to configure everything at once without navigating on the player you can change the config file (and this helps blind users, too). The decision what an 'advanced' setting is still remains, I would even go so far and say that everything that isn't on/off is advanced. example from the playback menu (only with an asterisk would stay in the menu): * shuffle * repeat play selected first ff rw fade on stop * party mode (*) crossfade (enable stays, everything else not) (*) replaygain (the same) * beep auto change dir (*) last fm (I never changed this, so I would remove it) cuesheet (*) skip length (don't know the point of this at all) From a user experience it doesn't change very much, most people won't even realise that they set a setting in a plugin.
RE: discussion regarding adding settings (PLEASE add your 2 cents)
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: [EMAIL PROTECTED] To: rockbox-dev@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.
Re: discussion regarding adding settings (PLEASE add your 2 cents)
Mark Ganson wrote: 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. But the binsize question will ALWAYS come up, so those who think it shouldn't be added just say Oh, binsize then it's back to the people who say it should be adding having to justify its binsize cost anyway. So why not just start out with them justifying the binsize cost in the first place? It's as simple as saying the largest binsize increase for this patch is on X target and is Y kilobytes. Considering this feature allows Z to be done, which was impossible before but necessary when using the player in this common situation, I feel it's easily worth the tiny increase after which everyone can look at the numbers, and whether they feel it's that commonly usable. Then the person justifying it could say well if we hard code it without a setting, and pick a small value so minimal bin is used, it only decreases the total bin use by X bytes, so if we have the feature at all it may as well be a setting because not having it as a setting doesn't offer a realistic savings. Or, y'know, a similar thing. Trying to make sure to present any negatives with the positives up front, instead of complaining every time people DO mention negatives, or dismissing those negatives by saying I think binsize doesn't matter, so quite complaining to me about it. As a note, Mark, you may not be aware but you're top posting which is something we ask users not to do on our lists.
Re: discussion regarding adding settings (PLEASE add your 2 cents)
I suggested moving the settings to a plugin a while ago on IRC, the major objections were: a) Voice isn't (yet) supported b) Requires a disk spinup (to load the plugin) each time you want to change a setting. Tom's work should resolve (a). For (b), I proposed that we allow the last-loaded plugin to remain resident (i.e. cached) so that unless you used another plugin, the settings menu would remain in the plugin buffer. We could even load it as the default plugin while the disk is still spinning at startup maybe - thus you'd never see an extra spinup until you ran another plugin. To do this would need a change to all existing plugins which have statically initialised variables; they would need to explicitly reset values on entry (or in some cases maybe choose to make better use of the cached model). Any takers? pondlife
Re: discussion regarding adding settings (PLEASE add your 2 cents)
Does anyone no what happened to that particular gsoc project? I'm still alive :). School and interviews have been kicking my ass for the past month or so and I've had zero time for Rockbox related work. The patch on the tracker is horribly out of date too. I sent my most recent work to Daniel and Stephane but even that is not ready for commit. I'm going to try and sync the patch for some review some time this week assuming I can find time. As a nice side-note, voicing does work in plugins after applying my patch, Ahh great to hear your still alive lol. I must say i'm really looking forward to your work being committed. It will be so good to be able to access dialogs such as properties and also play a few of the games such as chess or solitaire etc. Also, guess it will mean that maybe sdoyon can convert his patch to give playing time information for a play list into a plugin like he suggested he might a while back, and then it could get committed.
Re: discussion regarding adding settings (PLEASE add your 2 cents)
there is a solution. I'd propose this: battery bench doesn't use the plugin buffer at all, but steals his 512bytes from the main ram. So, stop playback - start battery bench - start playback again. There's also other plugins doing this. HI. I see, so am I following you right, your proposing that battery bench should be altered so that it doesn't use the plugin buffer at all? is that right? or is that how it now works? sorry I just found your english slightly hard to follow. Also, when you talk about stopping and starting playback isn't that something the user has to do already when there going to start the battery bench plugin. I no a blind user would have to at least, because at the moment of course, in order to use speech effectively you have to stop playback as its hard to hear speech when an audio file is playing, and you can't use speech when a file is paused. Sorry if i'm asking a really obvious question hear.
Re: discussion regarding adding settings (PLEASE add your 2 cents)
alex wallis schrieb: HI. I see, so am I following you right, your proposing that battery bench should be altered so that it doesn't use the plugin buffer at all? is that right? or is that how it now works? sorry I just found your english slightly hard to follow. Also, when you talk about stopping and starting playback isn't that something the user has to do already when there going to start the battery bench plugin. I no a blind user would have to at least, because at the moment of course, in order to use speech effectively you have to stop playback as its hard to hear speech when an audio file is playing, and you can't use speech when a file is paused. As of now it uses the plugin buffer. Using the main ram would remove the limitation to be not able to run other plugins. As for the playback: No, in it's current form it starts with active playback and it doesn't stop it. In my proposal you would need to stop the playback (in order to steal main ram safely). That's something that can be done automatically on starting though (mpegplayer and doom do it). I'm not sure what speech has to do with it.
Re: discussion regarding adding settings (PLEASE add your 2 cents)
As of now it uses the plugin buffer. Using the main ram would remove the limitation to be not able to run other plugins. As for the playback: No, in it's current form it starts with active playback and it doesn't stop it. In my proposal you would need to stop the playback (in order to steal main ram safely). That's something that can be done automatically on starting though (mpegplayer and doom do it). I'm not sure what speech has to do with it. Sorry, i'm probably mixing 2 issues up hear. I was thinking a user could start the plugin when playback was running, which would be hard for a speech user as you can only really use speech when a file is not running. forget my comment lol I think i'm mixing 2 issues which should be kept separate.
Re: discussion regarding adding settings (PLEASE add your 2 cents)
I'd propose this: battery bench doesn't use the plugin buffer at all, but steals his 512bytes from the main ram. So, stop playback - start battery bench - start playback again. There's also other plugins doing this. I assume those 512 shouldn't have a huge impact on the battery life. But this way, you couldn't only change settings while running a battery test (given that the settings menu is a plugin), but also could messure plugins impact on the battery life. The battery_bench callback mechanism works already quite nice and simple, if settings move to a plugin and tries to change a setting while battery_bench is running, the user will get notified. Why alter current behaviour and steal from audio buffer when the plugin itself is supposed to keep track of battery runtime without touching anything (most of the times at least)?
Re: discussion regarding adding settings (PLEASE add your 2 cents)
I'd propose this: battery bench doesn't use the plugin buffer at all, but steals his 512bytes from the main ram. So, stop playback - start battery bench - start playback again. There's also other plugins doing this. I assume those 512 shouldn't have a huge impact on the battery life. But this way, you couldn't only change settings while running a battery test (given that the settings menu is a plugin), but also could messure plugins impact on the battery life. The battery_bench callback mechanism works already quite nice and simple, if settings move to a plugin and tries to change a setting while battery_bench is running, the user will get notified. Why alter current behaviour and steal from audio buffer when the plugin itself is supposed to keep track of battery runtime without touching anything (most of the times at least)? Hi. because, what happens if a user wants to change a setting that impacts on how music is played back they wouldn't be able to do it if settings was turned into a plugin and battery bench was left in its current state. They would therefor have to disable battery bench, change the setting, run battery bench again and restart playback, you must admit that would be a very annoying situation.
Re: discussion regarding adding settings (PLEASE add your 2 cents)
alex wallis wrote: Hi. because, what happens if a user wants to change a setting that impacts on how music is played back they wouldn't be able to do it if settings was turned into a plugin and battery bench was left in its current state. They would therefor have to disable battery bench, change the setting, run battery bench again and restart playback, you must admit that would be a very annoying situation. The entire point of battery bench is that you should NOT be doing anything to trigger the backlight, change what's on the screen, spin the disk, or otherwise tax the player above and beyond basic playback preferably with the default WPS once you start the plugin. That would include changing settings. Taking a plugin's size from the audio buffer is exactly the opposite of trying to get an accurate benchmark (by the way, I doubt it's 512 bytes, it may not use the whole 512 kilobytes of the plugin buffer but that sounds extremely small). I mean all you'd be doing by moving the battery bench into the audio buffer would be making it even easier to create inaccurate battery benches, because they start of biased slightly toward a worse time than you'll normally see.
Re: discussion regarding adding settings (PLEASE add your 2 cents)
On Mon, Oct 27, 2008 at 7:00 PM, Thomas Martitz [EMAIL PROTECTED] wrote: I'd propose this: battery bench doesn't use the plugin buffer at all, but steals his 512bytes from the main ram. So, stop playback - start battery bench - start playback again. There's also other plugins doing this. I don't like this idea. This would mean: - execute code from outside a .text area. While this is possible I quite dislike the idea. Separating between code and data is something CPU manufacturers are trying to add (this no-execute thingy comes into my mind) to improve security. And for the mentioned plugins stealing the audio buffer: those plugins don't put their own code there but use it for buffering purposes (like doom putting the wad data in the audio buffer). Having plugins executing from outside the plugin buffer gives a bad taste. - stopping playback just for starting a plugin that didn't require that before? This simply sounds stupid to me as its quite a step backwards. Also, I don't like settings being a plugin -- Rockbox core should be self-contained, which implies that it shouldn't rely on any extra files. For the codecs this is not possible but all other parts should avoid this as much as possible. All functionality that currently is a plugin (properties and credits IIRC) isn't needed to use Rockbox. Changing settings is something I consider core functionality. - Dominik
Re: discussion regarding adding settings (PLEASE add your 2 cents)
alex wallis wrote: Hi. because, what happens if a user wants to change a setting that impacts on how music is played back they wouldn't be able to do it if settings was turned into a plugin and battery bench was left in its current state. They would therefor have to disable battery bench, change the setting, run battery bench again and restart playback, you must admit that would be a very annoying situation. The entire point of battery bench is that you should NOT be doing anything to trigger the backlight, change what's on the screen, spin the disk, or otherwise tax the player above and beyond basic playback preferably with the default WPS once you start the plugin. That would include changing settings. Taking a plugin's size from the audio buffer is exactly the opposite of trying to get an accurate benchmark (by the way, I doubt it's 512 bytes, it may not use the whole 512 kilobytes of the plugin buffer but that sounds extremely small). I mean all you'd be doing by moving the battery bench into the audio buffer would be making it even easier to create inaccurate battery benches, because they start of biased slightly toward a worse time than you'll normally see. But you can almost certainly guarantee there wil be at least one person who say decides they want to change an album so it gets shuffled for example. Yes I no that would lead to an inaccurate battery test, but i'm sure you will find there is at least one person out there who does that. Besides I like thomas's idea of being able to see what affect the use of other plugins has on battery life, it could make for some very interesting intertarget comparisons.
Re: discussion regarding adding settings (PLEASE add your 2 cents)
alex wallis wrote: But you can almost certainly guarantee there wil be at least one person who say decides they want to change an album so it gets shuffled for example. Yes I no that would lead to an inaccurate battery test, but i'm sure you will find there is at least one person out there who does that. Besides I like thomas's idea of being able to see what affect the use of other plugins has on battery life, it could make for some very interesting intertarget comparisons. So you're proposing make the Battery_Bench plugin less useful for its original purpose, by allowing it to be used for other things too. We need the battery bench as a decent means of comparing the battery life with the original firmware's, and for getting logged information on the discharge curves. It's not really something that needs to be expanded for other purposes at the cost of its core duty. Yes, people will misuse it by skipping tracks, but frankly we don't care what they do in their own private space since their misuse of it doesn't prevent or decrease the ability of the people using it properly to use it properly. Making it less accurate overall DOES decrease the ability of people who want to use it properly to do so.
Re: discussion regarding adding settings (PLEASE add your 2 cents)
On Mon, Oct 27, 2008 at 7:04 AM, Jonathan Gordon [EMAIL PROTECTED] wrote: 2008/10/27 Paul Louden [EMAIL PROTECTED]: For example, there's a legitimate argument that we could just compromise on the spacing value rather than making it accept a configurable string. Actually no, A simple strcat would be about as simple as it could be. Why does this make the argument unlegitimate? I don't want to get personal, but 80+ people have been given the privilege/right to change the code as they see fit, sure there is a level of trust going both ways that it wont be abused and that commits will benefit the community, but really, there has never been discussion about changing the authoritative structure to something less democratic, so in reality, commit discussions are a courtesy. The Why is it less democratic to require changes getting discussed before? IMO that's even more democratic as no single individual can simply do changes according to his / her liking but has to go through a somewhat democratic process first. While it wouldn't be helpful or a good idea to require all committers to do this on every single commit it isn't a bad idea on questionable commits, larger features and the like. but there is a line. I guess now is as good a time as any to bring up the usual problem where people will ignore discussion and then complain after commit. But anyway, This is not the topic... Well, I noticed some of these occasions got pointed to it was sitting on the tracker for x weeks afterwards. I always find this quite cheap, as the main discussion channels are IRC and the mailing list, not the tracker. Also, and this is something that in fact could be improved, the most discussions happen on IRC which is somewhat problematic due to different time zones and the discussions being mixed up with support and other talking, which makes it less convenient and more time-consuming to follow. At least I don't find the time to read through all logs, and I don't find the time to follow all discussions even when I'm online. A less synchrounous medium like email would improve that situation when it comes to questionable things, at least from my point of view. - Dominik
Re: discussion regarding adding settings (PLEASE add your 2 cents)
Unfortunately Rockbox has become quite feature-phobic recenlty. This wasn't the case a couple of years ago, where if the new feature in question was implemented correctly, it was mostly accepted without any thorough debate. The result was many and sometimes unneeded settings. Do I have second thoughts about them even if I (or a large userbase) don't use them? Hell No! For me that is the definition of Rockbox, Configurability. That is what is missing from OFs of other devices and that is the purpose of the project (to my view), to give more options(plugins/codecs etc) to the user (without of course lacking robustness, stability and usability). The way I see it is that for the sake of rombox on archos (and their low ram) most targets are drugged down. There is no real issue except those targets (which is indeed a problem). I've yet to see a benchmark that signifies lack of battery time resulted by settings overbloat (on high mem targets) and while there is a tiny decrease it is insignificant. The major increase in RAM usage came with dircache and Database (tagcache) which I think nearly all of us find them as the most valuable features (and luckily can be disabled to ensure less RAM usage). On the other side I am glad that we are nitpicky, that way we ensure that the best implementation is coded for inclusion. This though, is sometimes exaggerated and some new features are ostracized. In current situation even for the slightest settings addition you need at least 200-300 bytes even for a simple integer setting. Most of it comes from the settings-mechanism overhead and not the feature itself. The solution to this overhead could be separating the settings to a plugin, an idea which I dislike but if it allows us more settings I will happily welcome it. About performance and complexity there is not much to be said. Performance wise a new setting is responsible for another index on the settings structure (loading/saving no performance lost on that) and of course accountable for the changes or additions it introduces. Some settings can be a resource hog (mostly playback settings), while others are quite innocent with minor additions/changes to the core. Of course the setting in question should be refined and be as optimized as possible. New settings can make code more complex (not always though), but rejecting a new setting because is complex is like saying I don't want it because it is too difficult for me. I am lazy and afraid of touching that part of code because it might break it. In any case very complex settings are rare and all new ones should be included after making sure that they are less complex as possible. On the user side of things I haven't EVER heard of a user to complain about too many settings. That's in fact the grand attraction of Rockbox. The user that doesn't want or care about more options can just use the default firmware. I can understand frustration of not being able to customize something, but I will never understand why someone will complain of over-customization, it doesn't make sense. Yes, the settings menu could be more user-friendly but I don't find it too bad at all. It is logically separated in categories and the only problem more settings add to it, is that you might need to press more buttons to do what you want. Some setting-bloat haters could be pleased with a hidden advanced settings menu, which I don't understand at all (save for the fewer button presses), but again if that makes people happy I am all for it. Basically Rockbox development (again the way I see it), consists of 3 major parts: 1.New ports 2.Iron out bugs and optimization 3.New features or altering existing ones My opinion is that some developers would be very glad to strike out number 3 entirely or to limit it as possible. Based on their usage patterns they miss entirely why a new feature or setting could be needed. A feature almost always will introduce at least one new setting. Rejecting settings limits feature usage and without new features is like having an eternal feature freeze. Surely this is not something the project needs. It must evolve and get better. We all remember that some feature freezes in the past were introduced with lack of interest by contributors. In the end of course, developers decide what's best for Rockbox (and I hope they are right). I understand that it is impossible and impractical to have everything turned into a setting, but Rockbox is far away from that situation. I only resent what I might miss from future settings/features that will be rejected on the shrine of binsize and the doctrine of settings-bloat. :P For me that was the key feature, over-customization. That was the part that made Rockbox appealing and tempted me to add my own minor contributions. Most new contributors just like to make the project better by adding the content they thing is missing. P.S: This of course has nothing to do with FS#9455. It is understandable if it is deemed unneeded
Re: discussion regarding adding settings (PLEASE add your 2 cents)
XavierGr wrote: will be rejected on the shrine of binsize and the doctrine of settings-bloat. Can we please try to have this discussion without resorting to rhetoric and terms like this? And, as a point of interest, we're already using ~20-25% of the available RAM on the Cowon Coldfire-based players as it stands, binsize is not *only* important to the Archos players. We're also looking at players that only have 384kb of RAM, which makes binsize an even more significant hurdle for those (which will probably need a specially toned down build of Rockbox anyway). But the idea that we should accept *every* feature if it's coded well is, honestly, way over the top. Yes, feature acceptance has slowed down. So what? We can't always accept features at the same rate. Over time the biggest, most interesting features will be done. Our choice then, is slow down feature acceptance because the remaining features really aren't that worth accepting or begin accepting less worthy features in the name of simply being able to say we're still adding features at the same rate. Honestly, in my opinion, complaining that we're accepting features too slow is ignoring the fact that the project is quite mature now. We need to be picky about features. Yes, sometimes we're too picky, but the *rate* at which features are accepted is irrelevant since it's a function of the number of good features available rather than the height of the bar of acceptance. If we lowered the bar, we'd eventually slow down again as we run out of medium features. So while we're discussing this, let's keep it on what is the barrier of entry rather than talking about the rate of feature addition, which is a false metric.
Re: discussion regarding adding settings (PLEASE add your 2 cents)
Jonathan Gordon wrote: Put simply, my take on this issue is that I want more GNOME, and less KDE mentality. I may use 30 out of 200 settings. Now if we say that was cut in half, to 100 available settings, I might lose 10 settings. Would I miss them? Probably at first, but in my experience (from using GNOME through the slimming down of options), I'd quickly forget that I ever needed it, and frankly, taking away some choices from has made me focus less on the environment, and more on doing actual work. It seems, though that Rockbox developers, on average have more of a KDE-style mindset. -- Jonas Häggqvist rasher(at)rasher(dot)dk
Re: discussion regarding adding settings (PLEASE add your 2 cents)
On Mon, Oct 27, 2008 at 6:47 PM, Jonas Häggqvist [EMAIL PROTECTED] wrote: Jonathan Gordon wrote: Put simply, my take on this issue is that I want more GNOME, and less KDE mentality. I may use 30 out of 200 settings. Now if we say that was cut in half, to 100 available settings, I might lose 10 settings. Would I miss them? Probably at first, but in my experience (from using GNOME through the slimming down of options), I'd quickly forget that I ever needed it, and frankly, taking away some choices from has made me focus less on the environment, and more on doing actual work. It seems, though that Rockbox developers, on average have more of a KDE-style mindset. -- Jonas Häggqvist rasher(at)rasher(dot)dk I completely agree with Jonas. I think that there is too much focus on what can be customized rather than basic usability. Making /sane/ defaults for users is not such a bad thing. I do think though that gnome does a good job of having quite a bit of flexibility for power users that want to dive into gconf which leads to cause for having a separate plugin or application for advanced settings beyond the basic options. I think it is an excellent compromise between simplicity and power. The biggest complaint that I hear on Rockbox from non-techies is the usability; adding more settings does not solve the problem.
Re: discussion regarding adding settings (PLEASE add your 2 cents)
Can we please try to have this discussion without resorting to rhetoric and terms like this? The phrase was a tongue in cheek, that's what the smiley was about in case someone was offended by it. I don't get where the problem is with that. And, as a point of interest, we're already using ~20-25% of the available RAM on the Cowon Coldfire-based players as it stands, binsize is not *only* important to the Archos players. We're also looking at players that only have 384kb of RAM, which makes binsize an even more significant hurdle for those (which will probably need a specially toned down build of Rockbox anyway). It would be interesting to see the effect on battery performance now and when the targets where newly ported and/or how much the binsize increased. Sorry but my memory doesn't help me much. Which are these 384kb of RAM targets? (I hope that you don't mean the iFP). But the idea that we should accept *every* feature if it's coded well is, honestly, way over the top. I never said that, my whole point was not to be so rejecting at new settings; not to instantly accept all of them. It is the consensus that appears here that I try to avoid, that consensus later will be backed up on IRC discussions and finally a rejecting policy might be considered de-facto. Honestly, in my opinion, complaining that we're accepting features too slow is ignoring the fact that the project is quite mature now. We need to be picky about features. Yes, sometimes we're too picky, but the *rate* at which features are accepted is irrelevant since it's a function of the number of good features available rather than the height of the bar of acceptance. If we lowered the bar, we'd eventually slow down again as we run out of medium features. So while we're discussing this, let's keep it on what is the barrier of entry rather than talking about the rate of feature addition, which is a false metric. I wouldn't of course, expect the rate to be the same. As you say the project has matured enough so it is rather logical to have less and less features on the tracker.\ Again I must say that the point was not the rate, but the factor of acceptance. If it gets too negative it will be a major drawback for rockbox development.
Re: discussion regarding adding settings (PLEASE add your 2 cents)
2008/10/28 Paul Louden [EMAIL PROTECTED]: XavierGr wrote: will be rejected on the shrine of binsize and the doctrine of settings-bloat. Can we please try to have this discussion without resorting to rhetoric and terms like this? apparently not... 3 messages back from you agreed that it ALWAYS comes back to this. And, as a point of interest, we're already using ~20-25% of the available RAM on the Cowon Coldfire-based players as it stands, binsize is not *only* important to the Archos players. We're also looking at players that only have 384kb of RAM, which makes binsize an even more significant hurdle for those (which will probably need a specially toned down build of Rockbox anyway). RAM size to target count: 2MB - currently 0, 2 in the works 2- 8MB - 7 16MB - 4 32+ - 16 The old targets are holding us back. Most big features are #ifdefable out, and those that arntt, could be. To the people that really claim they want battery performace above everything, mind posting your config? I assume you have the file and playlist max size right down? last.fm, dircache, ramcache, cuesheet (unless you actually have any) all disabled? Thats an easy way to reclaim 2MB (Tried it on my beast). Using your own custom build with unused features disabled? Honestly, in my opinion, complaining that we're accepting features too slow is ignoring the fact that the project is quite mature now. We need to be picky about features. Why? since when should mature projects call it quits? the Linux kernel has been going for over 10 years now and its still adding lots of features.. are you saying its not mature yet? bringing in yesterdays IRC conversation about TV... CRT's could be considered very mature why bother upgrading the tech to LCD/Plasma? surely old outdated stuff is better? Besides, the only reason to use the maturity argument is to say that you want to consolidate the current feature set and get ready to package and sell it, who are we selling to? its always been about rockbox for the devs not the users.
Re: discussion regarding adding settings (PLEASE add your 2 cents)
XavierGr wrote: The phrase was a tongue in cheek, that's what the smiley was about in case someone was offended by it. I don't get where the problem is with that. Tongue in cheek or not, it creates a tone different from reasoned discussion. That's my point: Let's keep this without the jokes or asides. It would be interesting to see the effect on battery performance now and when the targets where newly ported and/or how much the binsize increased. A more reasonable test would be battery life now vs battery life now with RAM-eating functions removed (a build without several features compiled in at all). In many cases battery life has gone up, or not changed much, simply due to optimization despite increased RAM use. This doesn't mean that the increased RAM use wasn't harmful, just that we've compensated for it in those specific cases. Sorry but my memory doesn't help me much. Which are these 384kb of RAM targets? (I hope that you don't mean the iFP). Sansa Clip. The iFP has 1MB of RAM. I never said that, my whole point was not to be so rejecting at new settings; not to instantly accept all of them. It is the consensus that appears here that I try to avoid, that consensus later will be backed up on IRC discussions and finally a rejecting policy might be considered de-facto. You said all new ones should be included after making sure that they are less complex as possible with ones quite clearly being settings. This sounds, to me, like you're advocating inclusion of all proposed ones. But even if you're not, your proposal seems to be if we can't agree to reject them, we should accept them which basically just means you need a few vocal holdouts to include a feature that will negatively affect the silent majority. In the case of *not* adding features, it doesn't make Rockbox *worse* if a feature ends up getting turned down. Adding too many mediocre features, though, undeniably makes it worse in the general sense. I wouldn't of course, expect the rate to be the same. As you say the project has matured enough so it is rather logical to have less and less features on the tracker.\ Again I must say that the point was not the rate, but the factor of acceptance. If it gets too negative it will be a major drawback for rockbox development. Your first paragraph in the message I responded to was about a comparison of the *rate* of acceptance when you joined vs now. I assumed then that you felt rate was actually relevant since you made no mention of the ration of quality features accepted vs rejected. You even went so far to suggest that you were happy that unneeded settings were accepted. So, frankly, I felt you were talking about rate since that was what the introduction of your email was about.
Re: discussion regarding adding settings (PLEASE add your 2 cents)
2008/10/28 Jonas Häggqvist [EMAIL PROTECTED]: Jonathan Gordon wrote: Put simply, my take on this issue is that I want more GNOME, and less KDE mentality. I may use 30 out of 200 settings. Now if we say that was cut in half, to 100 available settings, I might lose 10 settings. Would I miss them? Probably at first, but in my experience (from using GNOME through the slimming down of options), I'd quickly forget that I ever needed it, and frankly, taking away some choices from has made me focus less on the environment, and more on doing actual work. It seems, though that Rockbox developers, on average have more of a KDE-style mindset. -- Jonas Häggqvist rasher(at)rasher(dot)dk That mentality doesnt even make sense... how are you at all disadvantaged by something you wont use? sure you might only lose 10 settings you use, but someone else might might lose 90.
Re: discussion regarding adding settings (PLEASE add your 2 cents)
I completely agree with Jonas. I think that there is too much focus on what can be customized rather than basic usability. Making /sane/ defaults for users is not such a bad thing. Having the option of customizing something doesn't hinder focusing on usability. Sane defaults are good but when hard-coded they can be very limiting. I do think though that gnome does a good job of having quite a bit of flexibility for power users that want to dive into gconf which leads to cause for having a separate plugin or application for advanced settings beyond the basic options. I think it is an excellent compromise between simplicity and power. With the paradigm of KDE vs GNOME things get more clear. While rasher likes GNOME better others find KDE more close to their usage patters. The matter of preference is very hard to resolve. The gconf analogy might be a conciliatory approach in the end. The biggest complaint that I hear on Rockbox from non-techies is the usability; adding more settings does not solve the problem. I think that's irrelevant. Usability will remain as it is in both cases unless someone starts improving it. (that was a project idea for GSoC 2008 BTW).
Re: discussion regarding adding settings (PLEASE add your 2 cents)
XavierGr wrote: Sane defaults are good but when hard-coded they can be very limiting. Sane, hardcoded defaults can also let you get on with your life, rather than waste your life configuring everything, and having unimportant configuration options get in the way of the actually important ones. -- Jonas Häggqvist rasher(at)rasher(dot)dk
Re: discussion regarding adding settings (PLEASE add your 2 cents)
Jonathan Gordon wrote: 2008/10/28 Paul Louden [EMAIL PROTECTED]: XavierGr wrote: will be rejected on the shrine of binsize and the doctrine of settings-bloat. Can we please try to have this discussion without resorting to rhetoric and terms like this? apparently not... 3 messages back from you agreed that it ALWAYS comes back to this. You seem confused, as I was referring to the terms on the shrine and the doctrine of, trying to frame the ideas in ridicule and humor rather than trying to hold a serious discussion. RAM size to target count: 2MB - currently 0, 2 in the works 2- 8MB - 7 16MB - 4 32+ - 16 The old targets are holding us back. Most big features are #ifdefable out, and those that arntt, could be. So we have 11 existing targets where RAM is, percentage wise, significantly decreased and 16 where it's not. That's not an overwhelming ratio. To the people that really claim they want battery performace above everything, mind posting your config? I assume you have the file and playlist max size right down? last.fm, dircache, ramcache, cuesheet (unless you actually have any) all disabled? Thats an easy way to reclaim 2MB (Tried it on my beast). Using your own custom build with unused features disabled? Yes to everything but a custom build. If you want to talk custom builds, add features to your custom build, but if I said I was using a custom build you'd just say well then you can ifdef out the new features anyway and you already know this is about the official Rockbox build, anyway. Why? since when should mature projects call it quits? Where did I say call it quits. I'm not saying we should be EXTRA picky. I think it was VERY clear from what I said that I'm suggesting we not LOWER our standards to increase the rate of feature inclusion. Please don't try to re-frame my statements to your own end. CRT's could be considered very mature why bother upgrading the tech to LCD/Plasma? This is a ridiculous argument. Tell how creating LCD TVs reduces the ability of someone with a CRT TV to use their TV. You're talking about telling people we're upgrading Rockbox to lower your battery life. Nobody's going into peoples' homes and shutting off features on their CRT TVs so that other people have more electricity for their LCD TVs. Honestly, if you're going to disagree with me, I'd appreciate you not go off on silly tangents. The question of maturity was, again, in terms of not *lowering* standards for the sake of an increased rate. Which is what this whole discussion is about. You're saying we're too demanding of new features. That our barrier of entry is too high.
Re: discussion regarding adding settings (PLEASE add your 2 cents)
how about bringing them back to a sane level like they used to be? another thing that adds nothing. study mode only got in because it was a drive-by-commit... oh and its still there... Sorry but I really have to disagree with you on this one, I wouldn't describe study mode or whatever it has been renamed to as mediocre or a useless feature. i really like the feature, its particularly useful for moving around in large audio books especially if whoever rips them doesn't rip them in sensible chunks but either leaves a file in one huge lump or has several hours in one file. yes yes I no you could edit the file if you wanted on the computer, but its extra work. Also for me at least as a blind user, it means i have a measure of control over fast forward and rewind, which is not that easy without study mode due to the fact that fast forward and rewind are not audible. at least this way i have a degree of control over movement within a file. Without study mode its very time consuming to fast forward and rewind through a very long file as you have to keep stopping and starting to find out where you are, at least you can be certain the time unit your moving by with study mode. Anyone else agree with me?
Re: discussion regarding adding settings (PLEASE add your 2 cents)
alex wallis wrote: But you can almost certainly guarantee there will be at least one person who say decides they want to ... Making decisions based on the at least one (hypothetical) person criteria is a recipe for extremes.
Re: discussion regarding adding settings (PLEASE add your 2 cents)
Sorry but I really have to disagree with you on this one, I wouldn't describe study mode or whatever it has been renamed to as mediocre or a useless feature.i really like the feature, its particularly useful for moving around in large audio books especially if whoever rips them doesn't rip them in sensible chunks but either leaves a file in one huge lump or has several hours in one file. That's the point. You seem to find the setting very useful while someone else considers it as mediocre. I could find 10 other settings that you find mediocre while I would like the and think they are helpful. So, instead of going by my habits solely I accept a setting that will not change neither your nor my preference. The whole discussion is summed up to: How to resolve preference conflicts and how aggressive should the rejection policy be.
Re: discussion regarding adding settings (PLEASE add your 2 cents)
2008/10/28 Paul Louden [EMAIL PROTECTED]: If they wouldn't make the cut, why are we even considering multifont? Why did we add conditional viewports? Why are we interested in positional list viewports and skinnable progress bar? none of these have a working patch yet, and yes there will be argument if/when they ever are ready. Clearly, some features that don't add functionality are still in the area of things we want. Since this isn't about any specific feature, I'd say these alone prove we're willing to consider features that aren't purely functional. So these are the only 3 features which will be considered in the next timeframe? why are they better than say XavierGr's patch? And as a note, study mode offers a very much improved ability to seek both quickly long distances, and finely afterward, in very large files. Something Rockbox didn't really have before. It was very easy to overshoot significantly with the previous seek method, if your target point was in the middle of a file. yes I know, I'm just saying that had it come up for discussion it would have been blocked, it didn't so it wasn't. So, claiming their insane is a bit much. It's clear we don't reject every feature out of hand, and in fact, if you look at recently rejected patches in the tracker I think you'll find there aren't too many you'd argue for inclusion of. you're putting words in my mouth... and well thats another point, patches arent outright rejected untill they come up for discussion, there are left to rot in the tracker. Is this about the actual barrier for entry, or is this just a complaint about the fact that people *will* debate (and possibly complain) about features that do enter, but they don't like. If we want to be democratic how can they be separate issues? Debate is fine (fun even), what we have in IRC after a contentious commit is not debate. what we have before a commit is not debate. Because honestly, you're not going to get people to agree to stop objecting to them, period. Meanwhile, evidence clearly shows we don't have that high a percentage of rejections, and very very very few reversions. We have a very high level of patch rot which is the same thing (some of the time), and yes reversions are something which is almost never done which is a very nice thing.
Re: discussion regarding adding settings (PLEASE add your 2 cents)
XavierGr wrote: The whole discussion is summed up to: How to resolve preference conflicts and how aggressive should the rejection policy be. Well, in the case of skip length it solves the fact that, prior to its existence, it was physically impossible to accurately seek in files blindly. So, in that sense, there was no workaround at all for users negatively affected (our entire blind userbase, I assume).
Re: discussion regarding adding settings (PLEASE add your 2 cents)
Jonathan Gordon wrote: you're putting words in my mouth... and well thats another point, patches arent outright rejected untill they come up for discussion, there are left to rot in the tracker. Which word? You said we need to bring them back to sane standards. By definition of the words themselves, that means the current standards must be insane. And plenty of patches get rejected without discussion. It's only patches in the mid-range that really get discussed. Patches that are good enough tend to have someone confident enough that it's done well, done right, and doesn't break existing behaviour that they sure it improves the user experience *for everyone* and so they commit it, and weather a few complaints. You're never gonna get everyone to agree, so it will *always* be an issue of your confidence. If the fact that a lot of people are complaining about it discourages you, you're probably not sure enough of the feature in the first place, I think. If we want to be democratic how can they be separate issues? Debate is fine (fun even), what we have in IRC after a contentious commit is not debate. what we have before a commit is not debate. Does what we have, before or after, stop you from committing? It's not a democracy, otherwise we'd vote on each feature and be done with it. So I don't get where this if we want to be democratic point even comes in. People complain. You listen to them. You try to decide if they have valid complaints or not. If there are valid issues, you attempt to fix or resolve as many as possible. You decide then if the feature is something you think honestly betters the project and then you move forward with it, or drop it. The weight is still on you as the feature author to make the decision, and to accept any consequences of the decision. We have a very high level of patch rot which is the same thing (some of the time), and yes reversions are something which is almost never done which is a very nice thing. We have a high level of patch rot because people put together half-assed patches and as soon as they work for unsupported builds, they don't try to address the problems. Even WANTED features usually rot because the author doesn't care enough to fix the problems with it. So it's not the same thing as rejection if we don't immediately snatch up buggy patches and commit them.
Re: discussion regarding adding settings (PLEASE add your 2 cents)
Jonathan Gordon wrote: 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. And you've heard dozens of times it's not *just* bin increase that's a problem, but whether a feature's bin increase is worth the functionality it adds. There's a finite limit on how much can and should be added (though we've not set a target maximum binsize there's lowmem targets already showing up anyway) if every feature that shows up is added, we're eventually going to have a binary that nearly everyone will agree is too big, and have to decide if we want to remove existing features. Better to keep mediocre features out in the first place, rather than having to remove features later. 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. There's a difference between having a powerful set of options and having the ability to configure everything you could imagine wanting to configure, plus some. 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… It's not usually about the setting itself, but whatever functional code it activates. Many suggested settings where this is objected are things like additional playback modes, etc, where there is a real maintainability problem. I'd be surprised if anyone's objecting to the maintainability of the struct itself. 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. But we can know how many people in the past have requested such a setting, or felt the lack of that setting is a legitimate problem. The problem seems to be distinguishing between bloat and legitimate bin increase. In my experience, your opinion is if someone wants it, it's not bloat and I think that's far too liberal. I think that every suggestion of a new feature needs justification. One shouldn't see people demand that I justify the binary usage as no feature should ever go in but simply binary IS valuable, and we need to make sure ever feature tries to use as little as possible, and ever feature that does get in is one we valuable enough that it we won't be considering removing it later for something else. That, generally, means a feature needs to do something that can't be achieved another way. For example, there's a legitimate argument that we could just compromise on the spacing value rather than making it accept a configurable string. Whether you agree that that's an acceptable way or not, it would mean a lesser bin increase, no added menu option, and no setting someone will debate removing later if we do run into binsize maximums. Now, at some point a decision needs to be made about every feature, but the idea that every single one should at least be challenged and justified shouldn't be thrown out.
