Avoiding Dvorak Keyboard Hostility

Dvorak users are divided between those that have the command keys in the Dvorak positions (and hence remember the equivalents by letter in the alphabet) and those that have the command keys in the QWERTY positions (and remember the equivalents by position on the keyboard). I'm in the latter camp.

Fortunately the system software supports both camps. The 'KCHR' resource allows you to create layouts for any combination of modifiers, and you can choose to point the command modifier to a QWERTY layout or a Dvorak layout. This works fine for the system MenuKey routine.

Unfortunately some programs choose to do their own command key processing. This is a big mistake IMHO. Still, if you're going to do it, you should do it right. The big problem is that they mask the modifier bits out of the key event that they pass to the system routine KeyTranslate. Because the command key modifier bit is not present, KeyTranslate uses the normal table. This is hunky dory when the normal layout is the same as the command layout (as in QWERTY and the first Dvorak camp) but is really annoying for Dvorak second campers.

Worse yet, some common command keys have pathologically bad mappings. For example, using my Dvorak layout if you hit command-X (for Cut), Acrobat Reader does a command-Q (and Quits).

These problems also affect international users; one Russian CodeWarrior user has complained bitterly to me about CodeWarrior messing this up.

The simple solution is to pass all of the modifier bits into keycode parameter of KeyTranslate. For most programs I can patch this behaviour in object -- I have successfully applied patches like this to Photoshop, CodeWarrior and others -- but some have compressed 'CODE' resources, which makes patch it very hard.

My Dvorak keyboard layout is available for on my web site.

I am working with various software developers to try to improve their Dvorak keyboard friendliness. One of these developers is Ramon Felciano, who has also written up a web page on the subject.

Note that the new system call, MenuEvent, which was added as part of Mac OS 8 to support menus with extra modifiers (eg command-shift-option-W) is Dvorak hostile. However, I still recommend that software developers use this routine, because it provides a central place where command keys are processed. This makes it easy for Apple to fix the problem (I've already filed it as a bug [Radar ID 1683232]) and for frustrated Dvorak keyboard users to fix the problem with a system extension.


Quinn "The Eskimo!"
22 Feb 1998