davidedmundson added a comment.
As for your comments: > The first one is, that the fading phases generate much DBus traffic, as you said. To solve this we would need to do the fading in KWin. For that we need timers, at least one. But it would make sense to have two timers, one for quick adjustments and one for long fades. >Because imagine the following: Not really. With any gradient or animation, you specify: startpoint, startvalue, endpoint, endvalue With that your "imagine the following" is easily solved, if you get a new sunset time or filter value you can immediately deduce the correct "current" value. (talking of which, look at QVariantAnimation instead of your quicksteps timer, it basically does the same thing, but wrapped away. Set the duration to the entire fade time, then use setCurrentTime on suspend) Also you shouldn't fear DBus traffic so much. Even if it was updating every second it wouldn't to be a problem. The suspend argument makes sense...though I'm not sure you can really use that argument whilst you currently have a call to logind in the code. REPOSITORY R108 KWin REVISION DETAIL https://phabricator.kde.org/D5928 To: subdiff, #kwin Cc: graesslin, davidedmundson, plasma-devel, kwin, ZrenBot, spstarr, progwolff, lesliezhai, ali-mohamed, hardening, jensreuterberg, abetts, eliasp, sebas, apol, mart, hein, lukas
