Page MenuHome

Keyboard shortcut mapping for macOS "Dvorak - QWERTY ⌘" layout
Needs ReviewPublic

Authored by Colin Kinloch (ColinKinloch) on Jun 4 2019, 8:10 PM.




In macOS the "Dvorak - QWERTY ⌘" keyboard layout is the same as the "Dvorak" layout but uses the QWERTY layout for interpreting shortcuts.

ActionQWERTYDvorak - QWERTY ⌘Dvorak

It does this by mapping key codes to QWERTY when the ⌘ key is held.

For reference, here is how the keyboard event mapping function, UCKeyTranslate, is used in some cross platform widget toolkits:


While using the "Dvorak - QWERTY ⌘" layout blender only reacts to "Dvorak" shortcuts.


This patch passes modifier (⌘, Ctrl, etc.) info for a keyboard event to the function used in macOS for mapping keyboard layouts, UCKeyTranslate.

This makes blender treat shortcut inputs as if the layout were set to QWERTY whilst in "Dvorak - QWERTY ⌘" as expected.

Diff Detail

rB Blender

Event Timeline

should be the same

Problem is that the _same_ could mean two different things: either the physical location on the keyboard, or the glyph.

I'm not sure what's expected, but I can think of good arguments for either of the above.

The layout lets you type using the dvorak layout without loosing the convenience of QWERTY shortcuts (ctrl+c, ctrl+v).

The UCKeyTranslate function requires the modifier flag to determine whether it should consider the key code a C or an J.

It's not clear from your description:

  • what was old behavior vs new behavior
  • why is new behavior more correct

How's this?

Do standard macOS apps work the same way? Which shortcut is displayed in the menus? Does this only affect Dvorak and perhaps some other specific cases, or does this affect a lot of international keyboard layouts?

As far as I know most macOS apps shortcuts are handled using the menu bar and NSMenuItem keyEquivalents and don't use UCKeyTranslate.

The QWERTY shortcuts are displayed on the menus in blender and the macOS menu bar.

I only have experience using "Dvorak - QWERTY ⌘" and QWERTY so I can't really speak for how other layouts work.

These changes were adapted from ones in this pull request to the godot game engine which also uses UCKeyTranslate to handle shortcuts in lieu of a menu bar.

This took me a long time to understand from the confusing and sparse description. It would be much easier if you just described what this was for.

What you are referring to seems to be a specific input keyboard layout on macOS called 'Dvorak - QWERTY ⌘', which uses DVORAK for normal text entry, but QWERTY for keyboard shortcuts.

What your patch does then, I suppose, is to support this input keyboard layout correctly? Does your patch correctly handle cases where users have specified other DVORAK styles?

Sorry about my ineloquence.

The patch doesn't effect the other dvorak layouts as they use the dvorak layout for shortcuts.

The patch changes two things:

  1. It uses the output of UCKeyTranslate for alphanumeric key inputs.
  2. It provides UCKeyTranslate information on what modifier keys are being held.

Change 2 is unlikely to effect anything for systems with keyboard layouts that don't vary when modifier keys are held.

@Colin Kinloch (ColinKinloch) I see - yes I guess this change makes sense. But, Blender makes heavy use of keyboard shortcuts without holding modifier keys - shortcuts like G, R, S and others. It would be inconsistent if those still were in DVORAK, but anything with a modifier (Shift, Control, Command, Alt) was using QWERTY.

So, how does this patch handle non-modifier key shortcuts?

G, R, S, etc. seems to be mapped in the same way as ⌘C is.

That is the QWERTY key G is moves the selected object.

One thing I just noticed, in blender 2.79 in the text editor pane neither the QWERTY nor dvorak copy and paste shortcuts work.

This patch seems to fix this.

Okay, in that case this sounds correct - haven't tested yet though.

Yeah, I'm actually pretty surprised it mapped G, R and S correctly.

Apple documentation is a mess.