The idea is to be able to control the scaling per-app alongside a global scale for each monitor. This will come in addition to all the other scaling controls. I feel like this would be a really cool feature to have, particularly for hi-dpi users on laptops
On a high DPI screen, if you reduce the scale of apps, you get more screen real-estate per app at the expense of legibility… but sometimes legibility is not very important (for example with note taking app), so you can scale those down and make more room for other apps. This is my main argument for this feature.
Some apps just have too big of a UI, or too small, and making them smaller or bigger would allow you to make better use of them, or to match their UIs with others.
Currently many apps allow you to zoom in and out (especially electron based app) and many dont. This idea would make all apps allow you to zoom in and out effectively.
I feel like this idea is best implemented on Wayland, since Plasma acts as the compositor so it would have control of the scaling better, and plasma on Wayland can already scale apps very well on different monitors.
To control the scaling, one can right click on the app’s title bar or task manager entry, and it’ll be under “More Actions”
If implemented, it would certainly be a very unique feature (among many offered by Plasma), and I don’t think any desktop environment or OS has it currently.
Interesting, was not aware this is possible. Will keep it in mind
However, this has the limitation that one can only control it while starting the app, not while the app is running. I’m proposing that this is adjustable while the app is running.
Also, this only works for KDE/Qt specifically. In my proposal, it would work for any app that supports scaling in general.
I understand what you mean that it’s a fringe use-case, and you’re right. Most people wouldn’t use it. One can say the same about other features like shading/unshading, per-window trasparency, etc. I feel like it’s a feature that one wouldn’t know would be useful until you actually have it and if it compliments the work you do. Many features in plasma are like that, and that’s why I like it so much.
I’d like to see more discussion here, and seeing what people think of it (advocacy, criticism, etc.), before opening a feature request.
the ability do ~ QT_SCALE_FACTOR in real time per window and config in places like “window rules” is something I been looking for in every KDE major release. This feature given a simple global shortcut like meta+alt+scroll or +/- would be used by me almost daily.
I would settle for being able to set the DPI for individual applications on launch.
With KDE and Qt applications setting QT_USE_PHYSICAL_DPI, QT_FONT_DPI, or QT_SCALE_FACTOR works quite well.
But it seems that the desktop DPI (scaled) is also somehow sent to non KDE applications in a way that is unaffected by these environment variables. For example, QT_USE_PHYSICAL_DPI=1 google-chrome doesn’t appear to change anything. On the other hand if QT_USE_PHYSICAL_DPI=1 is set before desktop initialization, the desktop then does appear to set whatever chrome reads to figure out the DPI.
I would settle for some wrapper app that I could use in the desktop file to launch the actual application phydpi google-chrome. Ideally a flag would be nice (run app at physical DPI).
My use case is I would like applications, such as photo-editors, pdf-viewers, and paint programs to all work at 1cm on screen equals 1cm on paper, and that pixel-peeping on screen is unscaled. Currently some applications feature an unscaled view (for example, gwenview), but others are scaling unaware, for example, when using a browser to assess images or documents, it’s not going to provide a native DPI preview - only starting the browser at native DPI is going to work.
At the moment I run my entire desktop with QT_USE_PHYSICAL_DPI=1 in .config/plasma-workspace/env/hidpi.sh, but is unsupported and that breaks the panel’s placement of menus and other popups. But is does have the effect of making all app’s preview images and documents at native DPI.
KDE used to provide the most flexibility for accommodating this use case, but running a desktop unscaled is no longer supported with various settings that enabled it now removed. Being able to run specific applications, both KDE and non-KDE at native DPI would regain some of the lost flexibility.
