search

lxqt / lxqt-config

Tools to configure LXQt and the underlying operating system
https://lxqt.github.io
GNU Lesser General Public License v2.1
81 stars 62 forks source link

XSETTINGS not applied correctly #1022

Open sledgehammer999 opened 1 month ago

sledgehammer999 commented 1 month ago

I have been evaluating LxQt in a VM for a possible future migration of my main pc to it. I noticed a few pain points and started to investigate. Luckily the code is hosted on github and it's online viewer/browser does wonders into researching the codebase without needing to clone the repos locally. I am also knowledgeable with Qt and C++ and I am willing to implement solutions if there is agreement to the direction. Enough chit chat, let me write about what I noticed.

Expected Behavior

Settings from lxqt-config-appearance should be applied consistently for Qt and Gtk apps. Settings should restore on session start. Available mechanisms for realtime "settings change" signaling to running apps should be used effectively.

Current Behavior

Some options from lxqt-config-appearance are applied inconsistently between Qt and Gtk. I can't remember all the stuff but I focused on the Font settings. All these settings are directly written to fontconfig files but they aren't saved into an lxqt config file. Qt/Gtk apps seem to pick up the font family from fontconfig but not the DPI setting. They pickup the DPI settings if I shoehorn it into the config file of xsettingsd. Same for Firefox. For whatever reason, writing the gtk-xft-dpi setting into settings.ini doesn't work for Gtk apps. Did Gtk deprecate it without notice?

For Qt apps, they can pickup a lot of those settings from the qplatformtheme plugin. Even though lxqt-qtplugin has code to inform the Qt apps about the normal and fixed fonts, the variables are initialized from non-existent config settings (lxqt-config-appearance writes the value only to fontconfig).

Currently, lxqt-config-appearance runs xsettingsd upon start with a temp file as config file. The temp file on each run has a random filename and is autoremoved when lxqt-config-appearance is closed. The xsettingsd deamon is also killed when lxqt-config-appearance is closed. This presents problems because when the deamon dies the XSETTINGS get wiped out. New (gtk?) apps can't get info about many of the settings configured by lxqt-config-appearance. It's common practice of all other DEs to have an xsettings deamon running.

Possible Solution
  1. All configurable settings should be written to lxqt specific config file first. From there they should be mirrored to their equivalent settings for Gtk and system (fontconfig).
  2. Upon lxqt-session start it should start xsettingsd with a non-temp config file. Upon settings change it should SIGHUP the running deamon to pickup the new settings.
  3. Maybe transfer the responsibility of the settings mirroring to lxqt-session?
  4. If step 3 is true, then should the session re-mirror the settings upon session start to ensure that they are synced with the saved lxqt settings?
  5. lxqt-qtplugin should read the settings from the lxqt specific config file.
  6. On Wayland I think gtk prioritizes the settings portal. What if xdg-desktop-portal-lxqt exposed the interface gtk expects and responded with the values saved in our own config file, without needing to fiddle with gsettings?

*Maybe we shouldn't fiddle with non-lxqt config files? What if we use xsettingds and a settings portal to propagate settings to Gtk apps and lxqt-qtplugin to propagate settings to Qt apps? We avoid writing to gsettings/settings.ini/gtkrc and leave them vanilla for other DEs the user might be running concurrently. This last thing is just a suggestion.

My main concern is about having an xsettings daemon running and what architecture changes are needed to do that. As a secondary importance, some configurable settings aren't mirrored to their xsettings and gtk equivalents currently.

Steps to Reproduce (for bugs)
Context
System Information
palinek commented 1 month ago

Your proposed solution sounds reasonable for me.

sledgehammer999 commented 1 month ago

@palinek I partially implemented this in PR #1023. If you're interested please take a look.