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
_______________________________________________
Kde-hardware-devel mailing list
[email protected]
https://mail.kde.org/mailman/listinfo/kde-hardware-devel
