Review Request 109792: Update 'dim display' algorithm.

[Danny Baumann]

Hi,

 >> Having said that, my current plan is the following:
>> - Drop the UI option
>> - However, leave the configurability via kconfig intact. That way, users who
>> are not happy with the defaults do at least have a remote chance of
>> changing it without recompiling KDE (after they found it's configurable, of
>> course - but there's a huge step between looking something up and compiling
>> a whole DE to change it) - Additionally add a dimRelative kconfig setting.
>> With dimRelative=true, dimRatio is interpreted as a factor
>> (dimmedBrightness = origBrightness * dimRatio), with it being false it's
>> interpreted as an absolute value (dimmedBrightness = 100f * dimRatio). -
>> The defaults are set up as dimRatio = 0.05, dimRelative = false
>> - Do the dimming in 2 steps, the first one being done after the configured
>> time, the second one 10 seconds later
>>
>> Is that approach ok?
>
> Nope, even a config key just adds maintainability and support burden. I've
> been there, done that, and didn't like the ride.
>
> The bug you are addressing is entirely fixable without an option, there is
> simply not a good reason to make this configurable.

So you say whoever is not happy with the proposed defaults (e.g. me) is 
suppposed to either recompile KDE or use another DE? My patch is _not_ 
addressing a bug only (although that ultimately was the trigger), but 
aims at improving the algorithm in the process.

(In case you're wondering, I'd like to make it dim to 30% of the 
original brightness to make it work seamlessly in the evening where the 
non-dimmed brightness is lower. I understand this may not be deemed a 
suitable default behaviour.)

Regards,

Danny