3 ms·

Apps in general either directly support high DPI or if dumb can be set to an integer scaling factor via environment. 99% of people are going to need exactly one

Apps in general either directly support high DPI or if dumb can be set to an integer scaling factor via environment. 99% of people are going to need exactly one variable for gtk apps that wouldn't be needed if gtk was just a tad smarter. Smaller changes can be handled with scale and mixed dpi by scaling down from higher res. Note the end result is again not blurry. You spend 30 seconds setting it up then every works including mixed dpi. In fact one could trivialize this at installation and write configuration to xorg.conf or xorg.conf.d One in general doesn't need to worry after setup if a particular app will work, if it will be wayland native or xwayland, if it will look different on different DPI displays, if it will be blurry, if all functionality will work. All high and mixed DPI concerns are front loaded into a tiny amount of time setting it up in a way that will just work well without compromise. A tiny amount of effort by your distro could easily erase even that by simply doing it for you. >IMO it is actually too nice anyway. Should have gone XDarwin all the way -- i.e. to run X11, you have to manually launch separate application, and that server does not support hidpi at all. This is an example of user hostility that goes a long way towards destroying adoption. Wherein your users and downstream projects like distros who actually care about user experience will take pains to avoid you. Then you can call them all luddites for caring more about working hardware than plumbing.

vetinari 4y ago
> Apps in general either directly support high DPI or if dumb can be set to an integer scaling factor via environment. I will again repeat myself there: and how does the display server know, if the app won't tell? > 99% of people are going to need exactly one variable for gtk apps that wouldn't be needed if gtk was just a tad smarter. Variables do not work in dynamic environment, where hotplug is a thing. Like personal computing in last 25 years or so. > You spend 30 seconds setting it up then every works including mixed dpi. In fact one could trivialize this at installation and write configuration to xorg.conf or xorg.conf.d So you are telling here, that: - there should be a database of apps; ignoring that the display server won't be able to recognize them solely on socket connection and it won't have another info available (no, Xresources is not a solution) - that database would be local system-specific - and it would be static, so if the user hot-plugs some hardware, it won't reflect the current system state anymore - and it would be static at runtime. If you want a change for a running app, you have to restart the app. Do you see some problems with that? The problem with this kind of thinking is putting hacks on top of another hacks and then wondering when the mountain goes down. > This is an example of user hostility that goes a long way towards destroying adoption. Wherein your users and downstream projects like distros who actually care about user experience will take pains to avoid you. How exactly did XDarwin destroy adoption of Quartz? If anything, it drove adoption. Instead of trying to hide the shortcomings, it exposed them and offered another solution, without them. > Wherein your users and downstream projects like distros who actually care about user experience will take pains to avoid you. Only those who prefer long pain; those who prefer short pain would do exactly the same. > Then you can call them all luddites for caring more about working hardware than plumbing. The entire point is that it does not work. Remember that when someone will complain that the monitor they plugged into their laptop doesn't do the right thing, unlike their Windows or Mac.
- michaelmrose 4y ago
  This is the totality of my present configuration In my shell config set -gx GDK_SCALE 2 Run once xrandr --dpi 163 --output DP-0 --scale 1.75x1.75 --output HDMI-0 --pos 3360x0 --mode 3840x2160 --output DVI-D-0 --pos 7200x0 --scale 1.75x1.75 Then saved to xconfig. This isn't automated because I really don't care because like many devices it only actually has one configuration but it would be trivial to do so by computing the exact scale based on difference in DPI. The one thing that can't be determined automatically is the physical layout. There are 17 different GUIs that amount to dragging around iconic representations of your screens. Autoscaling mixed dpi configurations could be a check box checked by default and writing to xconfig could be a button like it is in nvidia-settings. Other people prefer to simply switch between different named configurations with one of the 17 scripts that have been written to do this. The gist of why this arrangement needs to app specific configuration for proper behavior per screen is that as far as apps are concerned every monitor has the exact same DPI. Scaling is done by X not the app so if you were to say drag a window from monitor to monitor you would note that the window and its elements remains exactly the same size between monitor not because the app is smart but because X is. This is true enough that you can drag a window halfway between and notice no discontinuity between a line of text across both monitors. Note that this functionality isn't new nor does it require massive coordination or anything new at all. It has probably worked longer than you've used Linux.
  - vetinari 4y ago
    Great. So you managed the easy part - to scale your screen. The elephant in the room that you still ignore after several comments in this thread is, that the display manager cannot know magic variables for misc clients, it can barely tell clients apart (and it certainly doesn't know their image names, linked libraries or environment or how they were launched), and it shouldn't know, the clients should tell what resolution they are using so the display manager can adjusts their display. Wayland clients do that, X11 don't. No, you can't paper over it with some scripts. Suggestions like that always remind me this: https://www.youtube.com/watch?v=ZTdUmlGxVo0 https://www.youtube.com/watch?v=ZTdUmlGxVo0
    - 4y ago

vetinari 4y ago

> Apps in general either directly support high DPI or if dumb can be set to an integer scaling factor via environment. I will again repeat myself there: and how does the display server know, if the app won't tell? > 99% of people are going to need exactly one variable for gtk apps that wouldn't be needed if gtk was just a tad smarter. Variables do not work in dynamic environment, where hotplug is a thing. Like personal computing in last 25 years or so. > You spend 30 seconds setting it up then every works including mixed dpi. In fact one could trivialize this at installation and write configuration to xorg.conf or xorg.conf.d So you are telling here, that: - there should be a database of apps; ignoring that the display server won't be able to recognize them solely on socket connection and it won't have another info available (no, Xresources is not a solution) - that database would be local system-specific - and it would be static, so if the user hot-plugs some hardware, it won't reflect the current system state anymore - and it would be static at runtime. If you want a change for a running app, you have to restart the app. Do you see some problems with that? The problem with this kind of thinking is putting hacks on top of another hacks and then wondering when the mountain goes down. > This is an example of user hostility that goes a long way towards destroying adoption. Wherein your users and downstream projects like distros who actually care about user experience will take pains to avoid you. How exactly did XDarwin destroy adoption of Quartz? If anything, it drove adoption. Instead of trying to hide the shortcomings, it exposed them and offered another solution, without them. > Wherein your users and downstream projects like distros who actually care about user experience will take pains to avoid you. Only those who prefer long pain; those who prefer short pain would do exactly the same. > Then you can call them all luddites for caring more about working hardware than plumbing. The entire point is that it does not work. Remember that when someone will complain that the monitor they plugged into their laptop doesn't do the right thing, unlike their Windows or Mac.

michaelmrose 4y ago
This is the totality of my present configuration In my shell config set -gx GDK_SCALE 2 Run once xrandr --dpi 163 --output DP-0 --scale 1.75x1.75 --output HDMI-0 --pos 3360x0 --mode 3840x2160 --output DVI-D-0 --pos 7200x0 --scale 1.75x1.75 Then saved to xconfig. This isn't automated because I really don't care because like many devices it only actually has one configuration but it would be trivial to do so by computing the exact scale based on difference in DPI. The one thing that can't be determined automatically is the physical layout. There are 17 different GUIs that amount to dragging around iconic representations of your screens. Autoscaling mixed dpi configurations could be a check box checked by default and writing to xconfig could be a button like it is in nvidia-settings. Other people prefer to simply switch between different named configurations with one of the 17 scripts that have been written to do this. The gist of why this arrangement needs to app specific configuration for proper behavior per screen is that as far as apps are concerned every monitor has the exact same DPI. Scaling is done by X not the app so if you were to say drag a window from monitor to monitor you would note that the window and its elements remains exactly the same size between monitor not because the app is smart but because X is. This is true enough that you can drag a window halfway between and notice no discontinuity between a line of text across both monitors. Note that this functionality isn't new nor does it require massive coordination or anything new at all. It has probably worked longer than you've used Linux.
- vetinari 4y ago
  Great. So you managed the easy part - to scale your screen. The elephant in the room that you still ignore after several comments in this thread is, that the display manager cannot know magic variables for misc clients, it can barely tell clients apart (and it certainly doesn't know their image names, linked libraries or environment or how they were launched), and it shouldn't know, the clients should tell what resolution they are using so the display manager can adjusts their display. Wayland clients do that, X11 don't. No, you can't paper over it with some scripts. Suggestions like that always remind me this: https://www.youtube.com/watch?v=ZTdUmlGxVo0 https://www.youtube.com/watch?v=ZTdUmlGxVo0
  - 4y ago