David Wright composed on 2017-10-19 17:00 (UTC-0500): > On Wed 18 Oct 2017 at 19:22:53 (-0400), Felix Miata wrote:
>> Finding a wanted app to run from a classified tree list of 30 or 40 or 50 or >> more applications is easier for most people than remembering the name and any >> required startup options to type, both for those uncommonly used, and even >> for >> the commonly used ones if there are more than a scant few such. 2 or 3 or 4 >> clicks to start one up is typically easier than typing 4, 5, 6, 7 or more >> characters, or searching command history more than a few entries back. > Do you need a DE to do that? What's the difference between that and > the Debian menus that I occasionally use? Don't I? One of the few positive paradigms to come out of Redmond was the button at the lower left corner of the screen to open a tree-structured list of applications and utilities available to run. I've yet to see a materially better one that that derived from it for KDE2 or 3 that added a search box. >> It's a >> nice bonus in some DEs that automatically remember and reopen apps, their >> content states, and their window sizes and positions. > That's more debatable. Some people like that, some like me prefer > a particular setup whenever I start X, some use Place with Mouseclick, > etc. But there appear to be separate packages to handle this, like > lxsession and devilspie. I need all the help I can get to pickup where I left off when interrupted and forced to end the session before the WIP can be completed. >> For some, the microscopic default text size and fractional default >> proportion of >> screen area (80x25, using as little as 1/16 or less of total screen space) of >> xterm windows impedes their use for anything. > I've seen reports of fonts getting tinier as resolutions increase, > and not just on linux. I don't know how hard or easy it is to provide > sensible defaults for every application on every system, and in any > case circumstances vary. People with poor sight want large characters, > others want more characters on the screen. In the specific case of > xterm, I want and have both, and different fonts too, just by setting > different commandline options and Xresources. It's not resolutions per se, but resolution increases have considerable tendency to carry higher pixel density, notwithstanding the considerable average density differences between laptop displays and desktop displays. The problem comes from several sources: 1-Inconsistency from developers, some who size in pixels, and some who size in points. Points are resolution dependent, so are in principle unaffected by density. Pixels are entirely independent, so the higher the density, the smaller the container into which a fixed number of pixels fit. 2-As you imply, some want a bigger screen to provide for more stuff to fit, while others want the same stuff to simply be bigger, and yet others want a mixture of both. 3-Overall, computer developers are a youthful bunch, so their eyesight is better than average, while their collective wisdom has a lot of growing yet to do. Try to imagine anyone getting into computer development whose eyesight is materially poorer than average. That can be lot of pain to suffer day-in, day-out working on screens designed for use by people with better vision. There simply isn't much of it happening. 4-Hardware manufacturers are caught in the middle. They don't stay in business without making a profit. They know how to make higher quality product, but they're stifled by returns from those who after getting the product home determine their bigger screen makes things tinier and harder to use. So they limit the selection of high quality product, producing mostly native resolutions in physical sizes that produce densities near the arbitrary software standard of 96 DPI. 1366x768 in this day and age is hard to imagine, given that 1024x768 dates back over three decades, and 1080p dates back more than two decades. Yet, this is the resolution of both a typical 32" TV screen and a laptop of 15". Large PC screens ought to have an *average* density of at least 200 DPI by now, and have the software automatically doing the computations necessary to allow people to enjoy better quality and overall experience. 5-Much of development incorporates overwhelming perfectionism, a need to have results look "just right", not necessarily with any wisdom of the perspective of those with different eyes. Over-control is typical, limiting or even eliminating the ability to accommodate differing capabilities and/or environments. Computers are good at calculating, but developers routinely limit that utility. One of the most blatant of such constraints can be seen in Xorg: https://bugs.freedesktop.org/show_bug.cgi?id=41115 Please add option to avoid forcing of 96dpi an offshoot from: https://bugs.freedesktop.org/show_bug.cgi?id=23705 xserver forces 96 DPI on randr-1.2-capable drivers, overriding correct autodetection Xorg, as did XFree86, when broken hardware or firmware don't interfere, automatically calculates a display's size and resolution, resulting in a density capable of use by applications to display objects sized to accurate physical dimensions. That calculation is rarely used, as can be seen by examination of Xorg's logs. Accurate display density is reported, but in most cases it is "corrected" to a value fixed at 96 DPI, even when actual density is several times that. Too many different methods have been concocted for those who need and/or want it to workaround that disparity, instead of letting the computer do the computing. It's already been something like 5 years since web developers monkeywrenched CSS in similar manner. Standards expunged the physical lengths (cm, in, mm, pt, etc.) from conforming web browsers, keeping the nominal length names, but morphing them into logical units rather than physical. The only way to guarantee a physical size is to have total actual physical control of the hardware and of the software settings, and a display that does in fact have the same physical density as that applied by the server, usually 96 DPI. Relatively recently we got an additional impediment to functional workarounds courtesy of RedHat management through Gnome: https://bugzilla.gnome.org/show_bug.cgi?id=757142 Recent change breaks HiDPI setup based on calculated or forced DPI Those who find it desirable or necessary to manually configure the server instead of accepting random circumstance must provide a corresponding additional manual parameter otherwise unnecessary if they want their GTK applications obeying those configurations. This is nuts, and more seriously and circularly affects those already limited in ability. If you can't see tiny stuff in trying to accommodate (or personalize), how do you make the adjustments required to enable the accommodation? -- "Wisdom is supreme; therefore get wisdom. Whatever else you get, get wisdom." Proverbs 4:7 (New Living Translation) Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/