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