You guys need to have xsettingsd install with the update to plasma 5.27. Without it GTK apps don’t apply ui scaling.
2 Likes
Please read the reply from Nate to someone using that tool, see here This week in KDE: even better multi-monitor – Adventures in Linux and KDE
As far as I can tell OP isnt talking about mixed-scale multi-monitor (and makes no mention of X11 or Wayland).
But we can all read that is about xsettingsd - meant to add, outside of KDE Plasma, “support” for a mixed-scale for multi-monitor setup on X11, that according to the reply is never going to work properly. The reason is that all those GTK+ settings do not integrate with KDE Plasma Settings.
Wayland has implementation for the support of mixed-scale for multi-monitor setup, so it doesn’t need a third party daemon/service, reason why Nate suggest to use the Wayland session! instead.
I use a HiDPI laptop screen with no other monitors. I use X11 and have 200% scaling in Display Configuration. After the recent big update, Pamac had scaling issues. Many UI elements looked tiny. Installing xsettingsd fixed these issues. So I think @jackson has a point here.
Note that xsettingsd is an optional dependency for kde-gtk-config. But in the case of HiDPI screens, where most people apply >100% scaling, I think it should be a required dependency.
1 Like
Exactly, and will remain so, not a default for all installs.
Why not make it a default for all Plasma installs? What are the possible negative effects? It’s only 81 kB and has clear benefits for users who use HiDPI screens or are otherwise using non-100% scaling in Display Configuration (not a rare use case). Manjaro Plasma ships with Pamac by default and Pamac is a GTK app. It would be a bad look if the Add/Remove Software app, the thing every user has to use at some point, looks too big or small because of this notion that “if the Arch maintainers think this package is optional, then it must be optional in our distro.” Either it should be included or there must be clear negative side effects that would prevent inclusion.
This is what I thought. Nothing to do with multimonitor - just the scaling of GTK apps.
The only related mention I could find in arch wiki was this
https://wiki.archlinux.org/title/GTK#Theme_not_applied_to_root_applications
Now … the funny thing is that the article is more accurate than what is posted here because its true that theming isnt automatically picked up by GTK.
But on my system scaling is already globally applied using env var GDK_SCALE=1.25
So really … the hidpi configuration outlined in the wikis works fine.
(or by my script hidpify, which is pretty old now)
But for theming the wiki provides a solution of creating a few symlinks.
If I understand correctly it seems this package fixes both issues well and on-the-fly.
Manjaro may want to think about how to implement default KDE configuration and whether certain tools or settings, like the symlinks, are preferred or if this package is preferable.
Yes, that one for me is still the best there is, even tho you call it old, is none intrusive.
The xsettingsd.service from the xsettingsd will start also on wayland session without doing any good but rather flood the logs …
The ~/.config/xsettingsd/xsettingsd.conf will make the ~/.config/gtk-4.0/settings.ini and ~/.config/gtk-3.0/settings.ini not work , and if people will prefer for instance to have the close,maximize,minimize: instead of :minimize,maximize,close and set that up from KDE Plasma settings, they will be surprised that is not applying, especially if the GNOME/GTK Settings Synchronization Service is disabled from Background Services Settings in order to make scaling on dual-monitor dual-dpi work via xsettingsd …
One thing I’m curious about though is why it was working fine without xsettingsd prior to the stable update on 03-31. What was the change that now practically necessitates this package for non-100% scale users?
I’m also encountering more scaling-related issues: changing scale in Display Configuration used to give me a message about needing to restart to apply the setting. But now there’s no message and the new scale just applies in a haphazard way. Also, despite having installed xsettingsd, the Steam client is still unscaled. But I don’t know if it’s a GTK app.
EDIT:
I answered my own question. The answer is here:
https://wiki.archlinux.org/title/HiDPI#KDE_Plasma
ArchWiki says xsettingsd “should be installed.” So it seems the OP (@jackson) was right all along.
Please read the context. Is for those that need it. Is like insulin to diabetics, they should inject insulin, not the non-diabetics, unless they want to go into hypoglycemic coma.
Also Arch wiki continues with the next phrase after that:
And we have:
The practical thing to do is still to include it. Manjaro Plasma ships with and uses X11 and Pamac by default. There are a lot of users with non-100% scaling, including many HiDPI users. Including the package will thus benefit many users in a noticeable way.
On the other hand there are supposedly some minor negative effects for Wayland users and some tinkerers. For these users the solution is simple - just uninstall xsettingsd.
So the benefits outweigh the costs IMHO.
1 Like
Yeah, having no scaling on my 4k screen made GTK apps useless. And yeah, Manjaro plasma ships with and uses x11.
IMHO smaaky interpreted the context just right. Arch wiki says:
Note: Plasma 5.27 dropped use of GDK_SCALE/GDK_DPI_SCALE variables and switched to Xsettingsd. It should be installed to make scaling work for GTK apps. Or you can set this variables manually as described in #GDK 3 (GTK 3).
And also the man page of xsettingsd says:
It is intended to be small, fast, and minimally dependent on other libraries. It can serve as an alternative to gnome-settings-daemon for users who are not using the GNOME desktop environment but who still run GTK+ applica‐
tions and want to configure things such as themes, font antialiasing/hinting, and UI sound effects.
It seem like its exactly what a KDE desktop installation needs by default because every KDE user will use some GTK apps at some point.
And sorry I strongly dissagree with your diabetic anology. Literally every person I know has some sort of high dpi screen at home.
I am using Manjaro for over a year now and scaling has worked on and off randomly after updates and it is not a good feeling doing updates. I still have to figure out why steam is suddenly small again… that is really anoying.
Please consider making xsettingsd a dependency for kde-gtk-config if it is possible.
Dual screen 1920x1080 here, never had any issues whatsoever with GTK+ applications.
Yet the very next …
points on using those variables … So what part of it is true? More than that are still mentioned on Gtk – 3.0: Using GTK on the X11 Window System
The kde-gtk-config is packaged by Arch Linux, we inherit it from there, and xsettingsd is optional. Those who need it, can install it … like the insulin 
I can see you are either a really old school user or you are intentionally trolling me 
1 Like
The KDE Community Wiki recommends that xsettingsd be pre-installed:
https://community.kde.org/Distributions/Packaging_Recommendations#3rd-party_packages
IMHO, xsettingsd should remain an optional dependency of kde-gtk-config - not so that it can be installed, but so that it can be uninstalled. But Manjaro Plasma can and should have it installed by default.
@bogdancovaciu Hey, I got a suggestion. What about adding a way to install xsettingsd easily with Manjaro setting Manager. Maybe under GTK compatibillity section, something like “Apps scaling” and I bet there must be more GTK specific things like themes, etc that would make a KDE user happier when using GTK apps.
In an internal discussion with the team, a proposal, a way to do it, was via profiles. My honest concern about it is due to the inconsistency of it. A few issues i noticed in the past and mentioned previously got mostly fixed in KDE Plasma 5.27.4, but then i could reproduce the issue mentioned here on an older install after the update:
So the user already had it installed and working, and had to do all that uninstall/install again procedure.
On the other hand, i still noticed that, while setting now the scale in Display Configuration, values are modified simultaneously in the following files:
~/.config/xsettingsd/xsettingsd.conf the Gdk/UnscaledDPI is changed
~/.config/gtk-3.0/settings.ini the gtk-xft-dpi
~/.config/gtk-4.0/settings.ini the gtk-xft-dpi
I don’t quite understand why 3 files need to keep track of the same DPI settings, but let’s pretend it has to be that way. Is still better than previously when those files got out of sync really badly …
Currently my global scale is 100% so the value in question in all 3 files is 98304
I change it to 125% because otherwise i get
the values change to 122880 so, i switch back to 100% and … kaboom … the values do not change at all.
Changed to 200% applied and xsetingsd.conf has the 98304 value while the other two .ini files have the value 196608 … so i set to 150% and the .ini files still keep the 196608 and the xsetingsd.conf also gets that 196608 value.
Back to 125% xsettingsd.conf is 147456 (but wait, that is a different value i had previously when using the 125%) but at least now the .ini files also show that value …
I switch back to 100% and now the values are 122880 while should be 98304 because i’m back to where i started …
The GTK applications i had opened, not all got updated when applying, and some crashed during this process. So is not quite there yet …
KDE Plasma team is working on it tho Set DPI scaling settings for GTK on Plasma/X11 sessions (!49) · Merge requests · Plasma / KDE GTK Configurator · GitLab and probably in time will get even better.
On Wayland session things are more coherent in this regard.
Three configs is probally because GTK and GNOME devs can’t keep their standards straight, nothing new to me which is why I hate them and why they keep the whole Linux ecosystem back. But let’s stay on the topic.
I am wonderring why 98304 is 100%. But values seem consistent with 125% and 200% when it works.
My guess is that xsettingsd is a very buggy software, the reason I think so is because the reinstall fixed it, which it’s usually the case when using sofware brakes something but initializing of the configuration resets everything to “normal”. And why is that a deamon anyways? Does it need to notify someting after configuration has changed? Seems like a very weid design decision for a simple configuration.
And why the hell is the multiplier 6.25%??? Where is that message from?