On Mon, Jan 12, 2009 at 10:37 PM, Thomas Martitz
> This part is what I'm unsure about in our case. I see a number of people
> liking the backlight fading time configurability. But, based on the opinions
> some people on IRC threw in (they basically all said they don't change the
> defaults), I see the majority of people keeping the values at their
How about the majority of users? I bet those haven't been asked, and
even if you'd only get the opinions of those (most likely few) that
actually raise their voice, thus making a poll about this most likely
nothing near to representative.
Besides, the people discussing things on IRC are in most cases
developers, and its quite common that developers have noticably
different views than users.
> On the other hand, the few people at #rockbox that stated their opinion are
> representative at all, so my impression can be wrong. But it at least shows
> that the current defaults (short fade in, long'ish fade out) are not
> entirely wrong, I'd even they say are well chosen (I wouldn't change that
> behavior either).
The people at #rockbox are representative? For what group? Since when
is an arbitrary group of people representative? Also, I remember quite
some discussion (without a consensus) about what values are to be
> Dominik, what values do you prefer?
the values depend on target, thus it doesn't make much sense
discussing them here. Also, I'm pretty sure most people would choose
To go back to the main point: if the code handling the fading settings
is in fact too complex (but why? You have the values anyway, and why
should it make that much of a difference if the value is adjusted and
taken from a variable in the code instead of being a #define?) it
would be much better to make the code less complex instead of simply
scrapping features -- given the feature in question is actually useful
and used, which definitely is the case here.
Received on 2009-01-12