Mac OS X and Dvorak
Now, I don't want to get off on a rant here -- wait, what am I saying? Of course I want to get off on a rant. But first, some background, so you can understand what I'm ranting about.
I switched to the Dvorak keyboard layout several years ago when I was doing freelance writing. After a day of work on QWERTY, my wrists would ache; this problem went away entirely after switching to Dvorak. The speed benefits of Dvorak are marginal, from my experience, but it's so much more comfortable. Besides, it's handy to be able to type "shithead" without moving your fingers off the home row -- essential for Usenet flame wars. (My keyboard's still marked in a QWERTY layout, of course. This doesn't matter if you've learned how to type properly, i.e., without looking at the keys.)
The Mac has a facility for changing the keyboard layout in software. In theory, all you have to do is go to the Keyboard control panel and choose "Dvorak." (There's also a layout which Dvorak-izes the normal typing letters but keeps the keys in their QWERTY positions when you hold the Command key down, which some people prefer.) As usual, however, practice is different from theory. Each key on a Mac keyboard generates a key code, which bears little relation to the key's character code. For example, 'A' might be key code 1, but character code 65 or 97 depending on whether the Shift key is down. The key code is turned into a character code by passing it through a translation table called a 'KCHR' resource, which takes into account what modifier keys are being held down and what keyboard layout you've told your Mac you're using. The Dvorak layout, it is important to note, is implemented as a 'KCHR' -- and that's the root of my gripe. See, the OS passes the original key code and the resulting character code to application programs. Mac programmers often write their software to check for key codes rather than the character codes, simply because the key code doesn't change when a modifier key like Shift is pressed while the character code might. Not having to check twice for the same key (once with Shift, once without) has obvious appeal to programmers. Furthermore, in some programming situations, such as low-level system extensions, the raw key codes are all you can use.
Unfortunately, when looking at key codes, programmers tend to assume that the user is using a QWERTY keyboard or something resembling it. This assumption, and the resulting key codes, are of course completely wrong if you're trying to use a Dvorak layout. On pre-X Mac OS, this led to a variety of problems large and small with various programs, including Claris Emailer, OneClick, Apple Data Detectors, FinderPop, CopyPaste, and Conflict Catcher. Even the computer itself won't start up from CD by holding down C because the machine is thinking QWERTY, and Dvorak C is QWERTY I, which doesn't do anything. In mild cases this just causes the user to have to use the QWERTY layouts for certain keyboard shortcuts. In more severe cases, it caused features of the software to become completely non-functional. For example, the late lamented Apple Data Detectors posts a Command-C to the event queue to grab the text to be processed -- but it does it by key code. The C key on a QWERTY keyboard is Dvorak's K key. Command-K may or may not do something in a given application -- in QuarkXPress it deletes the selected object, I believe, which would be a bit of a surprise -- but in any case it is certainly not Copy. That's really minor, though, compared to trying to use OneClick, a macro program, with the Dvorak layout; in some cases you'd have to use carefully-constructed gibberish to get your scripts to type the right text because of the layout mismatch. It could be a real adventure.
Now, as it happens, the Mac OS has another keyboard-related resource called the 'KMAP.' The 'KMAP' is used to remap the key codes at a very low level, before any program outside the OS even sees them. The ostensible purpose of the 'KMAP' is to provide a way for the Mac OS to understand keyboards on which pairs of characters are not on the same key as US keyboard. For example, a UK keyboard will have a key with a £ symbol on it on the 3 key where the US keyboard has #. The 3 key on a UK keyboard might have the same key code as the 3 on a US keyboard, but it should not produce the same character codes. So, based on the keyboard ID number (which is 2 or 5 for US keyboards but something else for UK keyboards), a 'KMAP' resource is chosen to remap the 3 key to a new virtual key code which will later, when passed through the 'KCHR' table, result in the 3/£ key instead of 3/#.
By editing the 'KMAP' resources with ResEdit, it is possible to remap a QWERTY keyboard to the Dvorak layout at this lowest level, before any applications have had a chance to see the key codes. You then tell the operating system to use the "U.S." keyboard layout. Then key codes match character codes once again, and applications are happy. On USB Macs, the remapping can also be performed in the keyboard's USB driver with good results. I have used both approaches over the past few years. It has often been a pain in the ass to get everything working correctly, but I've managed to keep the balls in the air. It's true that if programmers didn't use the key codes when they should be using character codes, this wouldn't be a problem, but it's also Apple's fault for ever letting the key codes be out of sync with the character codes.
I could forgive this hassle on pre-X Mac OS; after all, back in 1984, when this whole 'KCHR'/'KMAP' scheme was dreamed up, hardly anyone was thinking of Dvorak. But Mac OS X has the same damn problem. I have three otherwise fine applications on my G4 right now that exhibit it: Drop Drawers, Get Info, and LaunchBar. To its credit, LaunchBar has an option in its preferences to tell it you're using the Dvorak keyboard layout, and furthermore, the developers of the other two programs have promised me they'll address the issue in future releases. Which is great, except I shouldn't need to tell every program on my Mac which keyboard layout I'm using, and programmers shouldn't have to worry about it either. It's not a problem on Windows, for God's sake. (On Windows 2000, which I use at work, you do have to type your login password in QWERTY, but once logged on I've never run into any problems related to the Dvorak layout.) I presume Mac OS X is using something like 'KMAP' and 'KCHR' resources, so something like the 'KMAP' hack ought to work, but I have no idea where to even start looking for 'KMAP' resources in X. Furthermore, under pre-X Mac OS the resource edits needed to be re-installed every time I upgraded or updated the OS, and Mac OS X is undergoing a lot of updating currently. There is really no excuse for this fundamentally broken implementation of Dvorak on a brand-new OS.
I guess that's really a pretty mild rant, although it's a good bit longer than I wanted it to be, but you'd think Apple, of all companies, would see the benefit of properly supporting a superior technology that suffers from a small marketshare. C'mon, Apple, let's see support for alternate keyboard layouts implemented in a smarter way, preferably at the driver or 'KMAP' level.
-- Jerry Kindall, 1/5/2002
