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.