I want to be able to control the kde plasma system settings from a shell script. I recently switched from Cinnamon and I had a shell script set to a key-bind that would change the value of the lid-close-battery-action to different values using gsettings. The problem now is that I can't find anything like that on kde-plasma.I found something called kwriteconfig but I found it pretty confusing, and if that is the way to go I would really appreciate some explanation. Thanks!

Hi!

You have multiple possibilities of changing the lid-close as it depends on the current energy-setting as on the special activity-setting if enabled. Have a look at systemsettings → Power Management → Energy Saving/Activity Power Settings.

What exactly do you try to change? gsettings is gnome-related, so these settings won't work (well, there are some cases…)

Thank you for the information! I am trying to make a shell script that will switch between the lid close action between suspending the system and just locking the screen, which then I can tie to keyboard shortcut. The reason for this is so that if I want to listen to music with the lid shut I can just hit they key combo and not have to worry about going into settings every time I want to do that, and shut the lid, but any other time the battery won't be wasted as much since the system would be suspended. Pretty much I'm just trying to automate a settings change from Konsole. If you have any suggestions on something that would be better please let me know!

The easiest would be to set up the Plasma Power Manager and uncheck the "pause media players when suspending" in the advanced tab.

If you want to script stuff, I always prefer DBus. The freedesktop-way is to use the loginmanager.
Get current event:

Code: Select all

qdbus --system org.freedesktop.login1 /org/freedesktop/login1 org.freedesktop.DBus.Properties.Get org.freedesktop.login1.Manager HandleLidSwitch


But this won't work for Plasma due to its powermanagement. I've looked into the Solid-stuff, but there seems to be no method to change LidClose, but you can lookup things or connect to the signals:

Code: Select all

qdbus org.kde.Solid.PowerManagement /org/kde/Solid/PowerManagement
qdbus org.kde.Solid.PowerManagement /org/kde/Solid/PowerManagement/Actions/HandleButtonEvents


So we're back to `kwriteconfig` and the file ~/.config/powermanagementprofilesrc. There you have to change the entries. Afaics this is separated by [profile][action] actionname=value, e.g.

Code: Select all

[LowBattery][HandleButtonEvents]
lidAction=2


So to change the lidAction to 64 (don't know the exact numbers, just grepping my config and 64 appears )

Code: Select all

kwriteconfig5 --file ~/.config/powermanagementprofilesrc --group LowBattery --group HandleButtonEvents --key lidAction --type int 64


Interesting topic anyways. I'm looking for some more dbus-stuff to get the actions named.

That solved the problem! The only other issue I have now is that even though the change occurs, it doesn't take place. Like for example in Konsole if I do ```kwriteconfig5 --file ~/.config/powermanagementprofilesrc --group Battery --group HandleButtonEvents --key lidAction --type int 1``` It does change that value to 1 but it does not apply the change so when I close the lid it does not lock the screen but instead sleeps like before. Is there some service that I need to restart or some command I need to run to apply these changes?

Normally it should work using kwriteconfig. You can try to run `kbuildsycoca5` manually to update the cache. The `dbus-monitor` only shows

Code: Select all

signal time=1650271401.991544 sender=:1.18 -> destination=(null destination) serial=296 path=/org/kde/Solid/PowerManagement; interface=org.kde.Solid.PowerManagement; member=lidClosedChanged


with boolean true or false.

Did you change all ProfileGroups or just the LowBattery-one?

Yeah that doesn't seem to work either, I see the value change in the config file and in settings but when I close the lid it still suspends the session. Though if I go into settings and manually change it and hit 'apply' it seems to take place. I only changed the [Battery][HandleButtonEvents] group.

Update:
I figured out how to use qdbus and ran the following

Code: Select all

dbus org.kde.Solid.PowerManagement /org/kde/Solid/PowerManagement/Actions/HandleButtonEvents lidAction

And it returned 1 even though I had just set it to 32 using:

Code: Select all

kwriteconfig5 --file ~/.config/powermanagementprofilesrc --group Battery --group HandleButtonEvents --key lidAction --type int 32

And just to make sure it wasn't because I was plugged in I disconnected to pc from the charger and got the same thing.
The thing is though, if I go into settings and manually change the value to what is equivalent to 32 then the same command outputs 32.
When I run just 'qdbus' not only do I get 'org.kde.Solid.PowerManagement' but I also get 'org.freedesktop.PowerManagement' it might be due to the fact that I switched from the Cinnamon desktop, but I am not sure. Maybe that has something to do with it but I doubt it since When I change the setting from settings it will change.

Untested: Try to send a signal yourself after changing the values

Code: Select all

dbus-send --type=signal / org.kde.Solid.PowerManagement.Actions.HandleButtonEvents.triggersLidActionChanged int32:1


If this does not work either, I have to look up the mechanism in PowerDevils source code ( → daemon source if you can read C++)

Yeah it doesn't seem like that works either.

Code: Select all

dbus-send --type=signal / org.kde.Solid.PowerManagement.Actions.HandleButtonEvents.triggersLidActionChanged boolean:true

must be a boolean. LidAction was the integer.

The code: short version:
As far as I can see (not a programmer ) it seems fine. What could break it is the presence of a second monitor (is configurable via Settings) and the signal we are using is the wrong one. The triggersAction is not the LidAction itself, it is the variable to check handling if more than one monitor is connected.
I'm now looking for another approach…

---

Long version:
The code:
Starting from connection powerdevilcore.cpp → Backends BackendInterface::lidClosedChanged → Core::onLidClosedChanged, which emits the signal lidClosedChanged( boolean: closed ). Also, it has the method to load/unload Actions which are defined in powerdevilaction-class, which has only a triggered-signal. Further in the powerdevilactionpool-class the actions are loaded as bundled actions which finally leads to handlebuttonevents-class adding some connections too. Did I mention that I love this abstraction. So easy to read and remember where I came from (Well, the KDE code itself reads nice! There's a lot of worse out in the wild).

So the handlebuttonevent is based on an DBus-Adaptor with its xml-representation in bundled/org.kde.Solid.PowerManagement.Actions.HandleButtonEvents.xml which is the part the Introspect gives us on DBus. Adaptors are a little magic to create needed classes on the fly without the need of writing them.
In the event-class everything seems fine, just the signal is the wrong one as already described above. So, I'm now looking for the config-changed() signals… to be continued…

Solution:

Code: Select all

kwriteconfig5 --file ~/.config/powermanagementprofilesrc --group Battery --group HandleButtonEvents --key lidAction --type int 64
qdbus org.kde.Solid.PowerManagement /org/kde/Solid/PowerManagement org.kde.Solid.PowerManagement.refreshStatus


I know, triggering a whole refresh is not a nice solution, but it works. I'm staying with the checkbox in the advanced settings as it works for me. Have fun

That solved it! Thanks for all your help!😄

Well, I'm using threads like this to learn. So, you're welcome