My 3¢
(I assume this is about the "dim after n minutes" feature, i only remotely
tracked the thread)
The config UI says "dim" not "alter brightness", so the behavior should simply be to
lower the brightness to n% of the present value ("n" being little enough to spot the difference but
not enough to turn it off) - and never brighten up.
If one wants to reach a certain brightness (because the weather alters between sun and clouds like
every 5 minutes or you move indoors etc.), one should use a slider plasmoid or whatever - the
"dim" feature is certainly not meant for such case (personally i use i as "time to
judder the mouse" hint ;-)
=>
- using a static value for dimming (even precompiled from the brightnes base
config) is wrong. It's even wronger when it can turn off the screen (since
neither is what the GUI suggests)
- demanding the ability to set a specific ratio or value is also wrong, since
that does really not seem the idea of the feature.
=>
as loong as a fix can ensure that the screen "significantly" darkens but does
not turn off, i don't think any more config key is required.
If this can *not* be guaranteed because HW vendors use any kind of unpredictable shit values for
the brightness range (like "-100 being least and -1 being max") the dimming factor needs
to be configurable and that needs to be exposed to the GUI ("fix ya hw") - otherwise it's
pointless, resp. hinting that the problem does not exist in reality.
The GUI could then come with a checkbox and be disabled by default.
Cheers,
Thomas
Sorry for TP, it's not directly related to Danny's particular mail.
On Donnerstag, 11. April 2013 17:59:03 CEST, Danny Baumann wrote:
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
