fix: switch input source via TIS instead of posting Eisu/Kana key events#115
Merged
Conversation
Apps with a custom text engine that bypasses the standard macOS input context (e.g. Affinity) don't treat a synthesized Eisu (102) / Kana (104) CGEvent as an IME switch — it lands as a literal half-width space instead. Switch the input source directly through the TIS API for these two outputs, for every app, instead of posting a synthesized key event. - Add InputSourceSwitcher: shouldSwitchViaTIS() is a pure, testable decision function; switchInputSource() does the actual TISCopyCurrentASCIICapableKeyboardInputSource / TISCreateInputSourceList + TISSelectInputSource calls (Japanese source preferring the standard Hiragana mode, silent no-op + NSLog if none is found). - KeyEvent.modifierKeyUp, keyDown/keyUp remap path, and mediaKeyDown remap path all route Eisu/Kana outputs through the new switcher and swallow the event instead of posting it; keyUp swallows silently to avoid switching twice. - Add tests for the swallow behavior and the decision function.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Problem
In apps with a custom text engine (e.g. Affinity Designer/Photo text editing), pressing a Command key inserted a half-width space instead of switching the IME.
Root cause: lone-Cmd switching posts synthesized Eisu (102) / Kana (104) key events via
CGEvent.post. Apps that don't route key events through the standard macOS input context never trigger the IME switch and instead interpret the injected key as a literal character (space).Fix
When a remap output is Eisu (102) or Kana (104), switch the input source directly via the TIS API (
TISSelectInputSource) and swallow the event, instead of posting a synthesized key event:TISCopyCurrentASCIICapableKeyboardInputSource()com.apple.inputmethod.Japanese); no-op with NSLog if none foundApplied uniformly across all remap paths (
modifierKeyUp,keyDown/keyUp, media keys). All other mappings unchanged.Verification
swift build— cleanswift test— 33/33 pass (new: swallow-on-102/104 tests,shouldSwitchViaTISunit tests)swiftlint— 0 errors (8 pre-existing warnings unchanged in category)Version bumped to 2.4.7 (triggers release on merge).