Thanks for the additional background info.
As you suggested, I’ve raised a bug around this particular capability “Request for a use-native-DPI setting” in which I’ve tried to outline the use-cases where such a setting might be important. I wasn’t sure exactly where it belonged, I raised it against kwin. Others may wish to add their own perspectives to the bug.
This option is really missed by me. Please, bring it back in Plasma 6. You can call me dumb or idiot, but only this option works for me. Adjusting the scale in the display settings doesn’t solve the situation. Everything becomes blurry. I hope the geniuses behind this project humbly pay attention to this request. Force Font DPI is very necessary. It doesn’t harm anyone and it’s another feature for the user.
Sorry for the late reply. I’ve been pretty busy the last couple of weeks. If you are still interested, I will gladly explain why I don’t want everything scaled on a global level.
The first and most simple reason is, that the size of most things is just fine. I don’t need everything to be bigger, because most things are just fine the way they are and I don’t have the need to fix something that is not broken.
The second Reason would be, that if I do scale everything globally, I would need to set it to 150% to get the document size match it’s physical paper version. So, my whole UI just gets insanely huge, which is just absolutely unnecessary and annoying.
What I don’t understand is, why you are writing about the dpi feature as it was some kind of wonky workaround constantly breaking things. I used it for years and it always worked fine. It just did what it said it would do – nothing more, nothing less. It was the only tool I needed to achieve what I think is a reasonable thing to want. I don’t had to tweak or tinker anything. I just used this feature as I think you initially intended it to be used.
I do see, that you probably have to deal with people, who don’t know what they are doing regularly. They click, tune and tweak everything they get their cursor on and ignore every warning you put in their way. This way they either find their workaround to something you would rather be notified about, so you can fix it, or it causes problems and breaks things, which they then come to you with. I can only imagine how tiresome and exhausting this must be. I do understand if you want to limit the ways people are able to sabotage themselves and the potential growth of the whole project. I just don’t feel great about this resulting in decreased usability
for people who used things as they were intended to be used.
Never the less, KDE Applications and the Plasma Desktop have become really awesome in general. I always liked and appreciated them very much and they constantly get better. The everything-work-properly-out-of-the-box-thing came a long way since I remember starting to use KDE. You all did a really great job here. Thanks for the effort and your willingness to discuss these matters with us.
A quick note for anyone reading this thread and wanting a workaround:
I’ve updated the bug-report/feature-request to include what is probably the most straight forward workaround to get the physical and desktop DPI into agreement, basically:
echo 'export QT_USE_PHYSICAL_DPI=1' >> /home/testuser/.config/plasma-workspace/env/hidpi.sh
(Perhaps this might eventually be set from a small GUI script. One that creates the setting and does a kwin-replace. Worst case it could require a re-login to bring it into effect.)
Thanks for explaining the use case, that’s really helpful.
@ngraham just to be sure I understand: the file ~/.config/kcmfonts is not taken into consideration in Wayland session, is it?
I mean, if I set it to
[General]
forceFontDPI=120
this will be considered only in X11, not in Wayland, right?
I had a look at the KDE bug report. Why has its status been set to “RESOLVED UPSTREAM”? IMHO, it isn’t resolved yet. Setting the environment variable QT_USE_PHYSICAL_DPI is an workaround for a specific case, but does not solve all issues. In particular, it relies on the EDID of the monitor to be correct.
IMHO, there are two (maybe three) settings which are necessary and they all have existed in old X11:
Please note, that the settings 1 and 2 serve two different purposes and hence these options should clearly be kept distinct.
Applications should use setting 1 (the DPI value) to correctly scale the objects displayed in their “workbench”. I use the term “workbench” for that part of an application which displays or manipulates objects of the real physical world. (Note, not every application has a “workbench”).
Applications should use setting 2 (the scaling factor) to scale their GUI elements (but not the representation of any actual physical object). The scaling factor is merely a mean to keep the GUI usable on high-resolution screens or as an aid for people with impaired eyesight.
I understand that it was the initial idea of the KDE developers to only have a single setting for both purposes. This means the idea was to exploit the global GUI scaling and set the scaling factor such that it corresponds to the actual, physical DPI value normalized to 96dpi. However, this a) does not work and b) should only be used for the purpose of GUI scaling.
Option 1: Physical DPI value
For all applications which have some kind of “workbench” which displays or manipulates objects of the real world it is absolutely paramount to know the correct DPI such that they can scale objects according to their correct physical size. (Software of this kind is e.g. LibreOffice or Inkscape which show some kind of “canvas” representing physical sheets of paper, any kind of CAD/CAE software like QCad, FreeCAD, etc.)
I have a 311mm × 175mm laptop panel (14" diagonal) with 2560 × 1440 pixels, i.e. a resolution of 209 dpi. Even if I set the global scaling factor to 209÷96 = 2,177 ≅ 215%, the program xdpyinfo | egrep resolution still reports the default pixel density of 96dpi. If the original idea was indeed to exploit the global scaling factor to correct for higher DPI, then that output should not be 96dpi but 206dpi. In particular, applications which are not KDE native, get the scaling of their workbench wrong. (GIMP is an example.)
Moreover, the scaling option only allows to set values in steps of 5%. This is to imprecise to get a correct scaling for “large” physical objects. There must also be an option to set DPI values like 209dpi or 94dpi.
Option 2: GUI Scaling factor
The scaling factor should merely be a mean to adopt the size of the GUI elements, but should no affect the scaling of the “workbench”.
If I set the scaling factor to 215% (as it would be “correct” for 209dpi on my 311mm × 175mm and 2560px × 1440px laptop panel), then the window decorations become so large that no space is basically left for the actual application. Personally, I have rather good eyesight and I like to have the GUI elements be scaled at only 120% (not 215%), because this provides me with more space for the actual application. On the contrary, someone with impaired eye sight might like to have 150% scaling even for 94dpi on a 520mm × 325mm and 1920px × 1200px monitor.
But as being said, in both cases the scaling of the applications “workbench” should be unaffected by that.
I am unsure whether a GUI scaling factor is strictly necessary. There is always also the option to adjust the GUI theme in the first place. But I admit that a global scaling factor is convenient. Nonetheless, an icon which has initially be designed at 24px always looks better than an icon designed at 16px and scaled up to 24px after-the-fact. Same holds for a menu bar which looks better if immediately rendered at 48px instead of 32px and then scaled up.
Option 3: Font DPI setting
I am indifferent wrt. to the third point. I believe it is not really necessary, even though I used that setting in the past myself. Actually, this option should be superfluous and already be covered by the scaling GUI factor. I only used it in the past, because with X11 the GUI fonts were scaled according to the physical DPI value (i.e option 1) and remained unaffected by the GUI scaling factor (option 2).
I think by resolved upstream the intent is that all application must be changed to fall into line with the new approach.
If applications want the true DPI, they are responsible for obtaining it and applying it. For example, Gwenview correctly displays images at an unscaled true DPI, so it must be retrieving the true DPI from somewhere.
I can’t say I like this resolution, it basically leaves users dead in the water until they can persuade application developers to make the required changes.
In respect to QT_USE_PHYSICAL_DPI, it is not the accepted resolution, there is no promise that that will continue to work.