SUMMARY Due to implementation details it's not possible to toggle Night Color from CLI. From documentations: Note that the inhibition lock will be released automatically when the service, which requested it, is unregistered. That means whenever you call `qdbus org.kde.KWin /ColorCorrect inhibit` from command line lock will be released instantly and you won't be able to hold it. That may be useful for user scripts that launch full screen games, media players, etc. For anything that isn't long-lived application which may connect to D-Bus itself (and most of the time it isn't even possible to make modifications to those apps from user side). STEPS TO REPRODUCE 1. Call `qdbus org.kde.KWin /ColorCorrect inhibit` from terminal OBSERVED RESULT Night Color isn't inhibited. EXPECTED RESULT Inhibit Night Color. SOFTWARE/OS VERSIONS Operating System: Arch Linux KDE Plasma Version: 5.18.5 KDE Frameworks Version: 5.70.0 Qt Version: 5.15.0 Kernel Version: 5.4.43-1-lts OS Type: 64-bit
Where is it documented that Color Correction and Night Color use the same D-Bus API?
>That means whenever you call `qdbus org.kde.KWin /ColorCorrect inhibit` from command line lock will be released instantly and you won't be able to hold it. Yes. It's the same as our other inhibitors Create the lock fork into the process you want the lock to hold over It'll magically quit when you exit
> It's the same as our other inhibitors > Create the lock > fork into the process you want the lock to hold over You're just citing what I said in first place. This behaviour is not a bug. And nobody said that it is. But implementation of inhibitors makes d-bus controller for Night Color completely useless for everything that isn't built-in applet. For this to work you should implement controller either on per-application basis (which cannot be done in case of closed source binaries as games) or by writing application which sole purpose is forking process to work around this behaviour just to be able to inhibit Night Color from CLI. Solution to this may be introduction of d-bus command for changing state of night color without needing to hold process for that. > Where is it documented that Color Correction and Night Color use the same D-Bus API? https://github.com/KDE/kwin/blob/master/org.kde.kwin.ColorCorrect.xml
>or by writing application which sole purpose is forking process to work around this behaviour just to be able to inhibit Night Color from CLI. Yes. Which is how powermanagement and other inhibitors work too, so you already need that wrapper.
> Yes. > you already need that wrapper The point is that writing program that will do that is beyond usable for average Joe. On the other hand firing D-Bus event from bash script is quite easy for anyone. So it probably makes sense to make a tool that will work with inhibitors available in KDE ecosystem. It may be not so helpful in case of power management (but probably there are cases there too) but for Night Color just to be able to play at night it annoys quite a bit to toggle Night Color every time.
Doesn't Night Color have an option to set the times when it should activate?
(In reply to Christoph Feck from comment #6) > Doesn't Night Color have an option to set the times when it should activate? I have a strong feeling that there are no single person on this planet who have a strict persistent schedule for opening full screen applications for their entertaiment. And it should be either limited by single time period or by local sunset/sunrise cycle. Doesn't seem practical. Schedule is fine for basic things like browsing and working with text. But if you occasionally watching movies or playing games it wouldn't work. Also it wouldn't work for people who work with art as a hobby, etc. If you sometimes do something that isn't reading/writing and it's dark outside you can't just add `qdbus org.kde.KWin /ColorCorrect inhibit && krita` to .desktop file and move on.
This isn't good solution though. I think the best solution is to add property to "Window Rules" which is dumb enough for everyone, already present in KDE and doesn't look as "hacky" as tinkering with launch options. It will be slick and easy for people who need it. On the other hand it fits well in current workflow and doesn't break anything for people who do not use Night Color.
FYI: https://invent.kde.org/plasma/kde-cli-tools/-/merge_requests/2
(In reply to David Edmundson from comment #9) > FYI: https://invent.kde.org/plasma/kde-cli-tools/-/merge_requests/2 That thing look quite simple yet solving annoying routine without too much of a hassle. Thank you!
Git commit 1f903bb93ce4fdc0f80268dcc23404ace542f70b by David Edmundson. Committed on 14/08/2020 at 15:04. Pushed by davidedmundson into branch 'master'. Add utility to inhibit various actions People want to use inhibitions with scripts, which is perfectly sensible. Most our inhibitors exit when the calling process quits, which is something we definitely want, but it fails when we have people making calls with qdbus/dbus-send and wondering why their inhibitions don't work. This tiny script puts surfaces all inhibitors in a way that's relatively easy to use from shell scripts. Related: bug 424288 M +1 -0 CMakeLists.txt A +3 -0 kdeinhibit/CMakeLists.txt A +95 -0 kdeinhibit/main.cpp [License: GPL (v2)] https://invent.kde.org/plasma/kde-cli-tools/commit/1f903bb93ce4fdc0f80268dcc23404ace542f70b