Request for a GUI

[romildo]

It would be very interesting to have a GUI for editing the settings and previewing them.

Any chance of adding one?

[derat]

Re previewing settings, are you specifically referring to font rendering? It's been a long time since I've looked at GTK+, but I think it always uses the settings that it picks up from XSETTINGS and other configuration sources, so I'm not sure that previewing is a possibility -- you might need to just update the settings and then see what apps look like. If you open a simple GTK+ app like gedit and then make changes to ~/.xsettingsd and run killall -HUP xsettingsd, does that let you see the changes?

Re adding a GUI for xsettingsd, it feels a bit out-of-scope to me:

• It would add a dependency on a toolkit like GTK+, Qt, or Motif, which is somewhat at odds with a desktop-environment-neutral XSETTINGS daemon.
• I suspect that most people who choose not to use GNOME, KDE, or another desktop environment that provides its own XSETTINGS daemon are already fairly comfortable editing config files.

Would it help if https://github.com/derat/xsettingsd/wiki/Settings had screenshots of text rendered using some common configs? The downside is that the same settings can result in different rendering depending on e.g. the version of FreeType that's installed.

[romildo]

I am thinking about something like LXAppearance (https://wiki.lxde.org/en/LXAppearance), but instead of changing toolkit configuration files directly (like ~/.config/gtk-3.0/settings.ini), it would change ~/.config/xsettingsd/xsettingsd.conf.

It would present options (like icon theme, gtk theme, font, etc.) for the user too choose from, and show how they would look like when applied. If they are saved, then the configuration file is definitely changed.

Maybe one can just change LXAppearance to save the configuration to ~/.config/xsettingsd/xsettingsd.conf

[romildo]

It would be a new optional application. Users can still directly edit the configuration file if desired.

It would be very helpful for those not using a desktop environment already providing ease ways to setting the configuration. There are plenty of window managers in this situation.

[ec1oud]

It's hard to believe: is there really no better way than editing the conf file and then kill -HUP? I see that these settings also show up in xprop -root RESOURCE_MANAGER but don't get updated dynamically (?). At least xprop -set exists, but it wouldn't be useful to set it that way unless something (like this daemon) was keeping the prop and the conf file in sync. And that's probably a bad idea for some reason. (As with everything on Linux it seems we have this too-many-fingers-in-the-pie problem.)

I know of at least two problems in Qt that XSettings might be able to solve: 1) dynamic theme switching (but the road is paved with what GTK does); 2) separate DPI per monitor: we're having a little debate about how to do it here: https://codereview.qt-project.org/c/qt/qtbase/+/376415

I was thinking of writing a tray application to switch the theme (because I want light/dark modes on my plain old openbox session), but am loathe to programmatically parse and rewrite ~/.config/xsettingsd/xsettingsd.conf and programmatically do the kill -HUP.

[xtaran]

Mainly to strike a blow for xsettingsd as it is without a GUI:

It's hard to believe: is there really no better way than editing the conf file and then kill -HUP?

This depends a lot on the viewpoint. From my point of view, xsettingsd is made and perfect for those who prefer a config file + their $FAVOURITE_EDITOR over a GUI. And yes, there are a lot of us out there. Or said the other way 'round: Editing the configuration file and killhupping the daemon is the best way, at least from our viewpoint.

If you want a GUI, there are a lot of bloaty settings daemons with inflexible and IMHO cumbersome GUIs out there, be it from GNOME, Cinnamon, MATE or XFCE.

[derat]

It's hard to believe: is there really no better way than editing the conf file and then kill -HUP? I see that these settings also show up in xprop -root RESOURCE_MANAGER but don't get updated dynamically (?). At least xprop -set exists, but it wouldn't be useful to set it that way unless something (like this daemon) was keeping the prop and the conf file in sync. And that's probably a bad idea for some reason. (As with everything on Linux it seems we have this too-many-fingers-in-the-pie problem.)

As I understand it, the settings that you see when you run xprop -root RESOURCE_MANAGER are unrelated to XSETTINGS. Those typically get loaded from $HOME/.Xresources or $HOME/.Xdefaults by the xrdb program.

I wrote down my 2014-era vague understanding of the X11 font configuration landscape at https://github.com/derat/font-config-info/commits/master/README.

I was thinking of writing a tray application to switch the theme (because I want light/dark modes on my plain old openbox session), but am loathe to programmatically parse and rewrite ~/.config/xsettingsd/xsettingsd.conf and programmatically do the kill -HUP.

I don't think you need to do any parsing, right? It seems like you could just write separate light.conf and dark.conf files and use a tiny script to switch between them, e.g.

#!/bin/sh -e
[ "$1" = dark ] || [ "$1" = light ] || (echo 'Missing light/dark arg' >&2 ; exit 1)
ln -sf "${1}.conf" "${HOME}/.config/xsettingsd/xsettingsd.conf"
killall -HUP xsettingsd

Or instead of a symlink, you could split your config into common and theme-specific parts and use cat common.conf "${1}.conf" >xsettingsd.conf.

[polypoyo]

I can think of a two good ways this could be implemented:

1. Reload the configuration file upon receiving USR1
2. Watch the configuration file using inotify (portability concerns)

[derat]

1. Reload the configuration file upon receiving USR1

This has been supported since pretty much the beginning (using HUP, not USR1). See 3d25cd4.