Dec 16, 2017
Make. It. Simple. Linux Desktop Usability — Part 3
After part 1 and part 2 of my series about #LinuxUsability (part 1, part 2 , part 3, part 4, part 5, part 6), this installment looks at the mere basics of system configuration such as keyboard and mouse settings. It is shockingly difficult to make today’s desktops speak your language, and mind-blowing that tasks which used to be simple 30 years ago have have become much more cumbersome over time.
The control panel
Here is the control panel from the Mac in 1984.
This was all there was to configure. Since then, things have grown steadily in complexity.
Boy, am I missing those times, where “stuff just worked”…
Desktops should have reasonable defaults that cater to the needs of the majority of users. Configuration options should be avoided where possible because they are only adding to complexity. If needed, configuration options should be hidden from “normal users” unless they are specifically looking for advanced configuration options.
Setting the keyboard language
In the first releases of the Macintosh System Software, the keyboard language was hardwired to the language of the operating system. So if you were running a German system, then it was assumed that you had a German keyboard, period. While this allowed for a very straightforward user experience, it was not very flexible and would hardly be suitable for today’s globalized world.
So, how could an easy way to localize the system look like? Fast forward a decade from the first Mac. Here is NeXTSTEP 4.2 from 1996 — one window to set the keyboard and the screen language, as well as the unit of measure and the paper size:
Takes a few seconds to set up everything.
Yet how hard can it be, two decades later, to set the keyboard to frigging German in GNOME? Let’s see (hint, hint, the video is six minutes long):
I never fully figured out whether this was GNOME’s or the distribution’s fault — but to their credit, it seems to be working better at least in some GNOME based distributions nowadays.
Still I wonder what an “Input Source” is, why I would care, and why I need none to have English but seemingly need one to have anything but.
So if the stated goal of “Input sources” was
We want to integrate input methods and keyboard layouts in a understandable, uniform way in GNOME 3
then you have failed in the most miserable way imaginable.
And no, it’s not just GNOME. Let’s have a look at openSUSE Tumbleweed KDE (hint, hint, not much shorter than six minutes either):
Or, let’s try Netrunner, a German distribution using KDE:
And once you finally have succeeded in setting up your keyboard language to match the actual hardware, it should not change all of a sudden because you inadvertently pressed some unknown, cryptic key combination like Alt-Shift (happens to me all the time in Windows) or Super-Space and Shift-Super-Space (on GNOME).
Why on earth would I ever want to switch to a “wrong” (that is, non-matching) keyboard language? Mac OS X had this, in my opinion, counter-productive menu:
So of course, we have a blown-up, more elaborate, version on the Linux desktop today— which I don’t need, either. After all, the print on my key caps doesn’t magically change either.
Desktops should automatically set the language based on the bCountryCode field in the USB descriptor data. As a fallback, “keyboard language” should be clearly visible in the topmost menu level of the control panel, and main languages like “German”, “French”, “Spanish” and so on should be reachable within one click, and should be obeyed by all OSes on a machine. Shortcuts that change between different keyboard languages should be disabled by default.
In the age of USB devices and (and USB device descriptors) it is always amazing me why apparently no one had the IQ to make operating systems recognize the language of keyboards automatically, after all the talk about “plug and play”. Not even Apple!
Boy, I should have patented this — or wait, someone must have had this idea before me. Right, indeed:
USB keyboards send keycodes that represent physical position of key on the keyboard, not the ascii/unicode key data. This is probably a bad thing in term of localization, but this is a protocol from the 90’s, they wanted to keep things simple, and keep the mindset of the PC/AT standard of the time.
Source: https://stackoverflow.com/a/39814973
The stupidity doesn’t end here. Someone did think about this, after all:
USB HID defines a
bCountryCodefield in the USB descriptor data (§ 6.2.1, p. 22) to this extent: Numeric expression identifying country code of the localized hardware.Unfortunately, this is underspecified (no distinction among variants of keyboards for the same language, etc.), so hardware manufacturers never used this field much, they nearly always put
0x00, i.e.NotSupported. Because hardware never used this much, OS support was never developed.
Oh well. So here we are, 33 years after the PC/AT standard, still having to set the language of our keyboards manually, even on shiny Macs.
The keyboard language should be set automatically to the language that is physically printed on the keys, without any user intervention. If that is not possible, then the keyboard language selection should be straightforward, and should be saved as a per-machine, rather than as a per-OS, setting (possibly even in the EFI/BIOS/firmware). Changing it on one OS should also change it for all other OSes on the machine. And it should be possible to attach different keyboards with different languages. Distributions should not have shortcuts set up by default that can make you inadvertently change the keyboard language.
(Update 2021: It was pointed out to me that some keyboards come with two sets of letters physically printed on the same keyboard. This is apparently common for Russian keyboards, with a Cyrillic set and an English set printed in a different color. For such keyboards, switching between the two sets should of course be easy and quick.)
Setting the mouse speed
Yes, getting the mouse speed right can be a science, but this complexity should be solved my the makers, not the users, of operating systems. In his Oral History recorded by the Computer History Museum, early Apple developer Bill Atkinson explains the importance of “mouse scaling”,
So that if you moved the mouse quicker, it would go more inches. The ratio of millimeters on the table to millimeters on the screen would increase when you went fast.
GNOME gets the usability about right:
Whereas KDE makes you need a PhD to set your mouse speed:
Not only does this look entirely unintuitive — where do I set my mouse speed, after all? — it is also worst-of-class and seems to conceptually lag behind as well:
In KDE, mouse acceleration is not logarithmic. That is, it has two constant mouse speeds: non-accelerated and accelerated. It switches from one to another when you jerk the mouse quickly enough. The first speed is non-configurable (at least, from GUI). The second speed is configurable.
Source: askbuntu.com
For experts, it’s of course great to optionally give them the power to use custom mouse acceleration curves (e.g., using additional tools not included with the desktop by default), but even then, it should be done in a way that is understandable:
A driver configuration for a mouse can include a custom acceleration curve. This curve can be one of the standard curves, a standard curve with an adjusted speed or sensitivity, or an entirely custom curve created point by point. [Details]
Source: ControllerMate
The mouse speed should be easy and intuitive to change by using one simple slider. Details should not be exposed to normal users. For experts, custom acceleration curves should be visually shown instead a bunch of numeric text input fields.
Direction of the scroll wheel
Surprisingly, I think Apple is to blame on this one, for the insane idea to change the direction of scroll wheels and touchpads “out of the blue” to make them “like smartphones” in what they called “natural scrolling” — even though there is absolutely nothing natural about it. They simply don’t seem to understand their own desktop metaphor anymore.
With the advent of OS X Lion, Apple began merging features of iOS and OS X. One of the most notable, simply because it was obvious to any Mac user who upgraded to any of the later versions of OS X, was the change to the default behavior of scrolling within a window or application.
Source: https://www.lifewire.com/how-to-change-scrolling-direction-on-mac-2260835
Apple calls the two scrolling systems natural and unnatural, but really, the unnatural system is the original system used by both Apple and Windows for scrolling a window’s content. The interface metaphor for displaying the content of a file was that of a window, which gave you a view of the file’s content.
Source: https://www.lifewire.com/how-to-change-scrolling-direction-on-mac-2260835
“Was?” Why “was?” This is still as true today as back at the time when the Apple team around Bill Atkinson invented the desktop metaphor.
Linux desktops — at least some — soon followed suit with the artificial “natural” scrolling. Because, you know, crippling time-proven desktop UX concepts with inferior mobile phone concepts is so “hip” today. But hey, this is Linux, so if there are two opposing ways of doing something you are 100% guaranteed to find two opposing ways to be the default on the Linux desktop! Ever since, it’s a total mess and you can never know which desktop uses which scroll direction by default. I’ll spare you the detailed comparison here.
“Natural scrolling” is confusing, breaks the basic scrolling metaphor and has no place on the desktop. Thus, it should not be the default.
Per-machine rather than per-OS settings
Many operating systems operate under the assumption that the whole computer is exclusively “theirs”, and there are no other instances of the operating system (e.g., an older version) or entirely different operating systems (e.g., multiboot) present on the same machine. Hence they don’t care about collaborating, e.g., treating basic settings such as language, keyboard layout, date and time, etc. as per-machine settings, and respecting them system-wide.
Setting the language
See how we set the language on Ubuntu-style Live ISOs:
live-config.keyboard-layouts=de live-config.locales=de_DE.UTF-8 live-config.timezone=Europe/BerlinOf course, every family of Linux distributions uses totally different cryptic strings.
Contrast this with, e.g., the Mac OS X 10.2 Installer (call it a “Live ISO” if you will) which boots straight into a language chooser:
Notice the simplicity and beauty of this.
Every Live ISO should boot into a straightforward language selector (that also sets the corresponding keyboard layout).
Storing the time
I am running a zoo of different Linux distributions on my machine using SystemImageKit (which allows me to choose from hundreds of Live ISOs at each boot).
One would expect that all of those systems display the time correctly. But guess what — they don’t. So my clock is off in virtually ever one of them.
Hey, this is 2017 and thanks to Intel our computers are running a secret MINIX operating system that includes networking and a web server all the time and is ridden with “vulnerabilities” (that the US government can potentially opt out through what is called the NSA “High Assurance Platform” ), yet we seem to be unable to use the hardware clock in a way that doesn’t totally mess up multi-boot. Can we use EFI NVRAM variables for storing the timezone?
Machine-wide settings using EFI NVRAM?
Apple has had something called the “Parameter RAM” (PRAM) since the first Macintoshes, an area in memory (powered by a battery) that would store per-machine settings, which would be respected by every operating system booted on a given machine — regardless of the hard disk or floppy the machine was booted from. The result would be that the basic settings like the keyboard layout and language would “just work” all the time. With newer Macintoshes, Apple is using EFI NVRAM variables for at least some of this. Is Windows using something like this, too?
Microsoft states:
Computers with Extensible Firmware Interface (EFI) firmware, such as Intel Itanium 2 processors, store boot options in NVRAM, a storage medium that can be edited, but retains its state even when you turn off the computer.
Source: https://docs.microsoft.com/en-us/windows-hardware/drivers/devtest/boot-options-in-efi-nvram
Can we do the same for the Linux desktop? Ideally even use the exact same EFI NVRAM variables that Apple and possibly Microsoft are using, in order to respect settings made in macOS on Linux and vice versa?
Linux distributions should pick a standard for how to set the hardware clock (e.g., UTC — check what Windows and macOS do), and then stick to it. So that booting different systems still gives you a correct clock. This should also work when booting Windows and/or macOS in between.
Someone should come up with a scheme for storing basic per-machine settings in EFI NVRAM, and get it standardized for all operating systems to implement — so that these basics “just work” as they did on the original Macintosh in 1984.
What do we make of this?
Discuss here or on the Twitter #LinuxUsability hashtag.
This article is part of a series (part 1, part 2, part 3, part 4, part 5, part 6) about #LinuxUsability.
probono is the founder and lead developer of the AppImage project. Screenshot editing was done using the same Krita AppImage working on different Linux Live ISOs. Screencasts were recorded using the Vokoscreen AppImage and edited using the Kdenlive AppImage. Screenshots from historic Mac OS X on PowerPC were made using the QEMU PowerPC AppImage on an Intel-based MacBook Pro running a Linux Live ISO.
