lxqt-config-appearance will start/replace xsettingsd even if GTK theme management is disabled

[M4he]

The LXQt appearance configuration dialog (lxqt-config-appearance) will start an xsettingsd instance even if its GTK theme management option is disabled.
This breaks any custom xsettingsd configurations a user might be running, because it will terminate those (only one xsettingsd instance can exist at a time).

Expected Behavior

If "Set GTK themes" is disabled in lxqt-config-appearance, opening up the appearance configuration dialog should not start a new xsettingsd instance or replace an existing one that wasn't started by lxqt-config-appearance.

Current Behavior

Even if "Set GTK themes" is disabled in lxqt-config-appearance, simply opening the appearance configuration dialog will start a new xsettingsd instance as:

/usr/bin/xsettingsd -c /tmp/lxqt-config-appearance.<random-string>

If an xsettingsd instance was already running (e.g. configured by the user) before opening the dialog, it is replaced by the dialog's.
When the appearance dialog is closed, its xsettingsd instance is also terminated¹. In case the user had a custom xsettingsd instance running before, it is not restored, effectively leaving the system running without an active instance¹.

¹ note: is this actually a bug of its own? I don't see the purpose of a dedicated xsettingsd instance if it terminates after closing the dialog. It has to keep running to be effective. (EDIT: see my comments below)

Possible Solution

a) check if the option "Set GTK themes" is set at the startup of lxqt-config-appearance and don't start an xsettingsd instance unless it's explecitly enabled

or

b) check if an xsettingsd instance is already running (which wasn't started by lxqt-config-appearance) and if so, do not replace it.

Steps to Reproduce (for bugs)

1. start a custom xsettingsd instance
   • e.g. xsettingsd -c ~/.xsettingsd (see here about configuration)
2. open up lxqt-config-appearance
3. observe your xsettingsd instance getting replaced (check your process manager)
4. close the appearance configuration dialog
5. observe that no xsettingsd instance remains running

Context

Users may want to use a custom xsettingsd instance (e.g. started via LXQt's autostart) containing custom tweaks and don't want LXQt to interfere.

LXQt's behavior is not obvious in this case. It does warn you about replacing ~/.gtkrc-2.0 and ~/.config/gtk-3.0/ stuff if you enable the GTK management but it doesn't notify/warn you that it replaced your xsettingsd instance.

System Information

• Distribution & Version: Debian 12 bookworm
• Kernel: 6.1.0
• Qt Version: 5.15.7
• liblxqt Version: 1.2.0
• Package version:

[M4he]

As noted in "Current Behavior" I have difficulties understanding lxqt-config-appearance's current behavior.

If GTK theme management is enabled, it correctly creates/overwrites ~/.gtkrc-2.0 and ~/.config/gtk-3.0/settings.ini. It also pushes the settings to

/tmp/lxqt-config-appearance.<random-string>

... which makes its xsettingsd instance propagate the settings via the XSETTINGS interface. See here for more details.

I currently don't see the point of the xsettingsd instance due to two reasons:

1. using the XSETTINGS interface effectively overrides any RC files (~/.gtkrc-2.0 and ~/.config/gtk-3.0/settings.ini) settings, since the interface takes precedence in GTK applications.

2. terminating the xsettingsd instance when closing the dialog makes it useless, since the XSETTINGS interface is a server/client architecture and the interface server (xsettingsd in this case) needs to keep running; terminating it makes all GTK applications fall back to the aforementioned RC files.

[M4he]

Okay now that I just wrote that down it occured to me: is it simply to refresh currently running GTK applications? Since changes to the RC files will only be read when a GTK applications starts, pushing it to a temporary XSETTINGS interface will refresh all running GTK applications?

That is actually clever (if that is the intent) however, the main point of the bug report remains. This should not be done if GTK theming is disabled and/or an existing xsettingsd instance is running.