Skip to main content

GSettings from GUI to Command Line

GNOME Logo

In GNOME, the user preferences are under the control of the GSettings subsystem. As GNOME is a graphical desktop, the usual form to interact with this is (doh) through a GUI. Recently I decided I want to mess with those settings also from the command line. Namely I wanted to quickly switch between disabling the screen blanking behaviour and its regular delay before activation. Changing this setting through the GNOME control center, requires me to grab the mouse, locate the control center, sift through all the menu options there trying to remember that it is below "Power" and finally changing it by using a drop-down menu. What I really want is a script called screenblank-toggle somewhere in my path. With such a script, I just type screenb <TAB> <Enter> without having to point the mouse or visually parse anything. The output tells me if the new situation is what I want and if not, <Arrow Up> <Enter> fixes it for good.

So to implement this, I need to find out what GSetting I am looking for.

dzu@krikkit:~$ gsettings list-recursively | wc -l
2662
dzu@krikkit:~$

Hm, maybe I can limit the search somewhat:

dzu@krikkit:~$ gsettings list-recursively | grep screen | wc -l
84
dzu@krikkit:~$

As I am too lazy to go through this individually, this small blog post shows a shortcut from the GUI to the command line without guessing names or reading documentation (ha ha).

Ideally gnome-control-center would just show me the name of the option once I found it in the GUI. It is not comparable, but something like the search in the Kconfig system of the Linux kernel would be nice. Maybe a hover popup? Anyway, as this is not available, let’s do it the generic way:

  • Snapshot all settings

  • Do the single change I am interested in

  • Find the difference between the snapshot and the new settings

Luckily this is super simple and so the following gsettings-diff script implements this:

#!/bin/sh

BEFORE=`mktemp /tmp/gsettingsXXXXX`
gsettings list-recursively > $BEFORE
echo -n "Ok, recorded current settings - now do the change and press enter ..."
read ANS
AFTER=`mktemp /tmp/gsettingsXXXXX`
gsettings list-recursively > $AFTER
diff -u $BEFORE $AFTER
rm $BEFORE $AFTER

Here is the sample run to find the parameter I am looking for. Before invocation of the script the screen blanking was set to activate after 10 minutes and during execution of the small script I disabled it:

dzu@krikkit:~$ gsettings-diff
Ok, recorded current settings - now do the change and press enter ...
--- /tmp/gsettings2k9NC 2021-03-29 20:16:38.164054726 +0200
+++ /tmp/gsettings1YSrB 2021-03-29 20:16:45.963988934 +0200
@@ -1028,7 +1028,7 @@
 org.gnome.Sudoku window-is-maximized false
 org.yorba.shotwell.video interpreter-state-cookie -1
 org.gnome.desktop.session session-name 'gnome'
-org.gnome.desktop.session idle-delay uint32 600
+org.gnome.desktop.session idle-delay uint32 0
 org.gnome.SoundRecorder audio-profile 'flac'
 org.gnome.SoundRecorder window-size [780, 480]
 org.gnome.SoundRecorder audio-channel 'stereo'
dzu@krikkit:~$

Ok, so the diff matches my expectation of a parameter to flip from 10 minutes to something else and I now know this something else is "0" and not "false", "disabled" or what have you. So this is all that’s needed. With that information the screenblank-toggle script that I wanted in the first place script follows naturally:

#!/bin/sh

set -- `gsettings get org.gnome.desktop.session idle-delay`
if [ $2 -eq 0 ]
then
    gsettings set org.gnome.desktop.session idle-delay 600
    echo Blanking after 10 minutes
else
    gsettings set org.gnome.desktop.session idle-delay 0
    echo Disabled screen blanking
fi

And that’s all. The availability of the gsettings command line tool hooks perfectly into the Unix toolkit to quickly make us more productive.

Writing this blog post took way longer than what I am talking about but I thought it may be a nice example of how the existence of the gsettings tool interfaces GNOME easily with the realm of the Unix command line. For lack of better words, those innocent looking little tools can make the difference between a "graphical user experience" and an "integrated graphical user experience".

Comments

Comments powered by Disqus