[PR #359] Show command shortcuts as typed on Dvorak - QWERTY layouts #358

New issue

Open

opened 2026-10-23 22:04:55 -06:00 by gitea-mirror · 0 comments

gitea-mirror commented

2026-10-23 22:04:55 -06:00

Owner

📋 Pull Request Information

Original PR: https://github.com/keycastr/keycastr/pull/359
Author: @monsterlag
Created: 10/22/2026
Status: 🔄 Open

Base: main ← Head: fix/issue-117-203a

📝 Commits (1)

6886786 Show command shortcuts as typed on Dvorak - QWERTY ⌘ layouts

📊 Changes

2 files changed (+36 additions, -3 deletions)

View changed files

📝 keycastr/KCEventTransformer.m (+11 -3)
📝 keycastr/KCVisualizerTests/KCKeystrokeConversionTests.m (+25 -0)

📄 Description

Note

AI-generated, not reviewed by a human. This pull request was written by an AI coding agent and then checked by a separate AI review agent, which re-ran the tests described below. No human has reviewed the code. It is submitted by @monsterlag, who runs these agents. If that does not fit how you want to receive contributions, please feel free to close it.

What

With the "Dvorak - QWERTY ⌘" input source, macOS switches the keyboard to QWERTY while ⌘ is held, so the key labelled J in Dvorak (QWERTY C, keyCode 8) triggers ⌘C (Copy). KeyCastr translated every key code with no modifier state, so it showed that shortcut as ⌘J. Same for ⌘V, ⌘X and the rest.

Fixes #117

How

-translatedCharacterForKeystroke: now passes the command modifier to UCKeyTranslate when ⌘ is down, so the layout's own command key map is used, which is the map macOS uses to match the shortcut. If that map has no character for the key, it falls back to the unmodified translation, as before. Only ⌘ is passed (not ⌃, ⌥ or ⇧), so the existing keycap and uppercasing rules are unchanged.

Effect on other layouts: I compared each installed layout's base map with its command map in a macOS 26.6 VM. US, ABC, German, French, plain Dvorak and the other Latin layouts I checked have the same characters with and without ⌘, so their output does not change. Layouts with non-Latin scripts (Russian, Greek, Hebrew, Arabic and others) map ⌘ to Latin letters. On those layouts ⌘C on the key labelled С now shows ⌘C, which matches what macOS shows in its menus. Please say if you would rather limit the change. This also matches what was asked for in #242 (Latin command letters on a Japanese Kana layout); happy to limit it to Latin-script layouts if you prefer.

How tested

On macOS 26.6 / Xcode 27.1, with submodules initialised. The project has no shared scheme that runs KCVisualizerTests, so I made a local, uncommitted scheme for that target. I also had to pass MACOSX_DEPLOYMENT_TARGET=12.0 because Xcode 27 rejects the project's 10.13 target: From Xcode, the new test runs like the existing ones: KCKeystrokeConversionTests in the KCVisualizerTests target.

Added test_dvorakQwertyCommand_commandShortcutsUseQwertyKeycaps to KCKeystrokeConversionTests. It loads the com.apple.keylayout.DVORAK-QWERTYCMD input source and checks that keyCode 8 shows j with no modifiers, and ⌘C (keycap C) with ⌘ held.
xcodebuild test -scheme <local KCVisualizerTests scheme> -destination platform=macOS MACOSX_DEPLOYMENT_TARGET=12.0 before the fix: the new test failed with ("⌘J") is not equal to ("⌘C") and ("J") is not equal to ("C"). After the fix: Executed 39 tests, with 0 failures, ** TEST SUCCEEDED **.
xcodebuild build -scheme KeyCastr -destination platform=macOS MACOSX_DEPLOYMENT_TARGET=12.0 CODE_SIGNING_ALLOWED=NO (signing disabled, since the project's team certificate is not available): ** BUILD SUCCEEDED **, with no new warnings in KCEventTransformer.m.

I did not test with a running app and a real Dvorak keyboard.

_{🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.}

## 📋 Pull Request Information **Original PR:** https://github.com/keycastr/keycastr/pull/359 **Author:** [@monsterlag](https://github.com/monsterlag) **Created:** 10/22/2026 **Status:** 🔄 Open **Base:** `main` ← **Head:** `fix/issue-117-203a` --- ### 📝 Commits (1) - [`6886786`](https://github.com/keycastr/keycastr/commit/68867862e47e4fe24fb73be0dae3e3c77a91fb4f) Show command shortcuts as typed on Dvorak - QWERTY ⌘ layouts ### 📊 Changes **2 files changed** (+36 additions, -3 deletions) <details> <summary>View changed files</summary> 📝 `keycastr/KCEventTransformer.m` (+11 -3) 📝 `keycastr/KCVisualizerTests/KCKeystrokeConversionTests.m` (+25 -0) </details> ### 📄 Description > [!NOTE] > **AI-generated, not reviewed by a human.** This pull request was written by an AI coding agent and then checked by a separate AI review agent, which re-ran the tests described below. No human has reviewed the code. It is submitted by @monsterlag, who runs these agents. If that does not fit how you want to receive contributions, please feel free to close it. ## What With the "Dvorak - QWERTY ⌘" input source, macOS switches the keyboard to QWERTY while ⌘ is held, so the key labelled J in Dvorak (QWERTY C, keyCode 8) triggers ⌘C (Copy). KeyCastr translated every key code with no modifier state, so it showed that shortcut as ⌘J. Same for ⌘V, ⌘X and the rest. Fixes #117 ## How `-translatedCharacterForKeystroke:` now passes the command modifier to `UCKeyTranslate` when ⌘ is down, so the layout's own command key map is used, which is the map macOS uses to match the shortcut. If that map has no character for the key, it falls back to the unmodified translation, as before. Only ⌘ is passed (not ⌃, ⌥ or ⇧), so the existing keycap and uppercasing rules are unchanged. Effect on other layouts: I compared each installed layout's base map with its command map in a macOS 26.6 VM. US, ABC, German, French, plain Dvorak and the other Latin layouts I checked have the same characters with and without ⌘, so their output does not change. Layouts with non-Latin scripts (Russian, Greek, Hebrew, Arabic and others) map ⌘ to Latin letters. On those layouts ⌘C on the key labelled С now shows ⌘C, which matches what macOS shows in its menus. Please say if you would rather limit the change. This also matches what was asked for in #242 (Latin command letters on a Japanese Kana layout); happy to limit it to Latin-script layouts if you prefer. ## How tested On macOS 26.6 / Xcode 27.1, with submodules initialised. The project has no shared scheme that runs `KCVisualizerTests`, so I made a local, uncommitted scheme for that target. I also had to pass `MACOSX_DEPLOYMENT_TARGET=12.0` because Xcode 27 rejects the project's 10.13 target: From Xcode, the new test runs like the existing ones: `KCKeystrokeConversionTests` in the `KCVisualizerTests` target. - Added `test_dvorakQwertyCommand_commandShortcutsUseQwertyKeycaps` to `KCKeystrokeConversionTests`. It loads the `com.apple.keylayout.DVORAK-QWERTYCMD` input source and checks that keyCode 8 shows `j` with no modifiers, and `⌘C` (keycap `C`) with ⌘ held. - `xcodebuild test -scheme <local KCVisualizerTests scheme> -destination platform=macOS MACOSX_DEPLOYMENT_TARGET=12.0` before the fix: the new test failed with `("⌘J") is not equal to ("⌘C")` and `("J") is not equal to ("C")`. After the fix: `Executed 39 tests, with 0 failures`, `** TEST SUCCEEDED **`. - `xcodebuild build -scheme KeyCastr -destination platform=macOS MACOSX_DEPLOYMENT_TARGET=12.0 CODE_SIGNING_ALLOWED=NO` (signing disabled, since the project's team certificate is not available): `** BUILD SUCCEEDED **`, with no new warnings in `KCEventTransformer.m`. I did not test with a running app and a real Dvorak keyboard. --- <sub>🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.</sub>

gitea-mirror added the

pull-request

label

2026-10-23 22:04:55 -06:00