-
-
Notifications
You must be signed in to change notification settings - Fork 46
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
xsettings: Set Xft.dpi in X resources to scaled_dpi #368
xsettings: Set Xft.dpi in X resources to scaled_dpi #368
Conversation
This makes it match Xft/DPI in XSETTINGS. Applications relying on Xft.dpi on HiDPI screens will now work correctly. Behavior is now consistent with GNOME, relevant commits from gsd: https://gitlab.gnome.org/GNOME/gnome-settings-daemon/-/commit/047f030235972fdab5e15aff484006caf914216a https://gitlab.gnome.org/GNOME/gnome-settings-daemon/-/commit/25c7cc703118c69b224acf9c4f7af09a31f50a34
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
While I do not have any known examples of the apps in question, I didn't get any ugly surprises running this either. Needs testing by someone who has an application relying on this.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This definately applies the DPI changes. On further testing this was clearly visible in Conky when set to use XFT. We DO get some issues handling fonts ourselves at 196DPI it seems, they come out rather thin, but if this is what we get with behavior consistant with GNOME, this means fonts need to be changed in HiDPI cases to fonts appropriate for such resolutions.
QT (at least with qt5ct) seems to have problems with this setting, though that's not for us to fix I suppose: I found QT apps rendering all text double-size, reducing text size in qtctl to 6 (rendered as 12) was a partial workaround.
Anyway, if this is consistant with the rest of the computing world, we need to merge it, otherwise fonts that work in GNOME etc won't look right in MATE on HiDPI.
QT apps giving me some inconsistant behavior, due to their own implementation of hidpi support. Played with turning window-scaling-factor-qt-sync on and off (and restarting the session) and it seems that no setting gets icons, text, and padding right all at once. Best results were setting text size to 5px (rendered as 10) in qt5ct and keeping window-scaling-factor-qt-sync turned ON. Kdenlive looked best with it off and 10px text-except that gave icons half the expected size with mostly normal padding.That setting also made Audacious's (old-style not GTK) control window and equalizer render half-size. There too I had to reduce text size. Note that this is a very old app, a fork of XMMS which I first used 16 years ago |
Qt5 HiDPI detection has been broken for me pretty much always (in GNOME also), so I have to keep this in the environment: Note that Without the fix in this patch, additional DPI override is required, like this for 2x screen: |
What means XFT ? |
|
Ok, another application to test is
So i think it's better to disable the env Edit: |
Best results for all my KDE applications i got if using |
Did you disable the workaround before testing?
|
I have this setting disabled, and I also made sure there are no |
The ONLY thing that worked for me on Debian was to set Unfortunately doing this in .bash_profile , .profile etc were ignored |
Another combination of options that seems to produce good results in my case is: Regarding envrionment variables, things you set in |
I think everything in
But it is important to disable the .......I hope i will find time today to test your proposal. |
@OleksandrChekhovskyi |
I did another test with
This is working for me fine too. |
That is essentially what I used. Fixed the QT issues, still had oversize text in the main menubar of git-gui, so that
must be picking up the dpi but missing something else-and only missing it in its main menubar, which is wierd. What toolkit does that use?
Audacious, kdenlive etc all rendered correctly with this.
There is no way we can fix all the hidpi bugs of all toolkits from here, it's rather a matter of staying with the standards everyone is converging on, and getting the best real-world results that CAN be controlled from our code.
On 4/12/2021 at 4:11 PM, "raveit65" ***@***.***> wrote:
I did another test with
```
From 1494c8811e4b277dd766ab7901850b26762376d4 Mon Sep 17 00:00:00
2001
From: raveit65 ***@***.***>
Date: Mon, 12 Apr 2021 21:57:28 +0200
Subject: [PATCH] update_qt_scale v.2
---
plugins/xsettings/msd-xsettings-manager.c | 6 +-----
1 file changed, 1 insertion(+), 5 deletions(-)
diff --git a/plugins/xsettings/msd-xsettings-manager.c
b/plugins/xsettings/msd-xsettings-manager.c
index 5247523a..9e1dcd78 100644
--- a/plugins/xsettings/msd-xsettings-manager.c
+++ b/plugins/xsettings/msd-xsettings-manager.c
@@ -534,14 +534,10 @@ scale_change_workarounds
(MateXSettingsManager *manager, int new_scale)
gsettings = g_hash_table_lookup (manager->priv-
>gsettings, INTERFACE_SCHEMA);
/* If enabled, set env variables to properly
scale QT applications */
if (g_settings_get_boolean (gsettings,
SCALING_FACTOR_QT_KEY)) {
- if (!update_user_env_variable
("QT_AUTO_SCREEN_SCALE_FACTOR", "0", &error)) {
+ if (!update_user_env_variable
("QT_AUTO_SCREEN_SCALE_FACTOR", "1", &error)) {
g_warning ("There was a problem
when setting QT_AUTO_SCREEN_SCALE_FACTOR=0: %s", error->message);
g_clear_error (&error);
}
- if (!update_user_env_variable
("QT_SCALE_FACTOR", new_scale == 2 ? "2" : "1", &error)) {
- g_warning ("There was a problem
when setting QT_SCALE_FACTOR=%d: %s", new_scale, error->message);
- g_clear_error (&error);
- }
}
} else {
/* Restart marco */
--
2.31.1
```
This is working for me fine too.
@OleksandrChekhovskyi
I am still wondering why only using this setting doesn't work for
you?
I am using fedora 34 beta with newest qt and kde versions and
***@***.*** use debian-testing.
…Maybe you#r using an olther qt or kde versions and those guys did
make some improvements?
--
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub:
https://github.com/mate-desktop/mate-settings-
daemon/pull/368#issuecomment-818142183
|
These settings seem to produce better results in various scenarios. Link to discussion: mate-desktop#368
I've added the second commit with I wonder myself why Just for reference, I'm on latest Arch, which means everything is as up to date as possible. Qt5 is at |
Note that I use Debian Unstable, not Debian testing. Now on to the latest test I just tested the |
Also I just verified that the git gui menubar font problem is not affected at all by QT settings being turned on or off. git-gui depends on the Tk toolkit, no idea where that is now supposed to stand on hidpi support |
Yes, git gui use Tk toolkit. I don't think that much programs use this nowadays. @vkareh |
Additional thoughts on the matter:
|
Given that there were no objections on this approach, maybe let's land this already? |
@lukefromdc @rbuj |
On the road at rhe moment, but all my tests have been on a 4K monitor
|
Just retested, 4K monitor as usual. Good results on conky, kdenlive, Audacious, qt5ct so now I just have to find some way of dealing with git gui's very old Tk toolkit on hidpi with Xft.dpi correctly set |
I switched from |
Also |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM,
this fixes several problems with HIDPI windows and runs fine.
All values are set up fine now.
This makes it match Xft/DPI in XSETTINGS. Applications relying on Xft.dpi
on HiDPI screens will now work correctly.
Behavior is now consistent with GNOME, relevant commits from gsd:
https://gitlab.gnome.org/GNOME/gnome-settings-daemon/-/commit/047f030235972fdab5e15aff484006caf914216a
https://gitlab.gnome.org/GNOME/gnome-settings-daemon/-/commit/25c7cc703118c69b224acf9c4f7af09a31f50a34