Related sample project: https://github.com/vChewing/vChewing-macOS/tree/f6271bbf50a2c377d9c2095d0f31f1492a653aef
It seems that individual bug reports doesn't work at all. Besides, the entire InputMethodKit needs a renovation.
This thread will be sent to Apple by certain special approaches after gathering enough usable information.
Let's talk about what InputMethodKits needs to improve. Here's my conclusion. If Apple think there's already an API, then it might be either mulfunctioning or not exposed to Swift.
-
An official Swift-friendly wrapper with neither "!" nor "?" in the parameters of all provided APIs.
-
Provide effective official exposed Swift access to:
- { get set } WindowLevel of the IMKCandidates, making sure that it won't get covered by NSMenu and Spotlight by default.
- { get set } Default candidate fonts as NSFont
- { get set } Highlight background color of the IMKCandidate panel
- { get set } Window background color tint of the IMKCandidate panel, allowing developers to enable or disable aero-glass transparency.
- { get set } Candidate keys definable in both ways: charCodes and keyCodes.
- { get set } Get the currently-highlighted TOTAL INDEX of the chosen candidate in the current candidate window.
- { get } Add IMKTextInput.isWritingContextVertical.
- { get } Add currentMarkedRangeOrigin (NSPoint), currentMarkedRangeTopLeft (NSPoint), currentMarkedRangeTopRight (NSPoint), currentCursorOrigin (NSPoint), currentCursorTopPoint (NSPoint).
-
IMKInputController.Candidates() can send (Candidate, Reading, Annotation) triplet to the IMKCandidates. Also, IMKInputController.candidateSelected() and IMKInputController.candidateSelectionChanged() retrieves both Candidate and its total index number in the candidate window.
-
Add Home / End key support in the IMKCandidate window.
-
Provide a clear and unified Swift API for sending key NSEvents to IMKCandidates, making sure that these sent events are handled there. At least,
- (BOOL)handleKeyboardEvent:(NSEvent *)event API_AVAILABLE(macosx(10.14));
needs to be officially exposed to developers. -
Add official NSEvent support of detecting whether Shift key has been pressed as a single function key. This is for helping IME developers to provide their own in-method input mode switch. This feature is crucial for users who already got accustomed to how Windows input methods behave. Reasons:
- Ergonomics: "Ctrl" / "CapsLock" / "Fn" key are less friendly than "Shift" key to one's pinkle finger.
- macOS built-in CapsLock IME toggle can have 1-second latency on certain user's computers with totally unknown reasons.
- Most Chinese IME users are from Windows, inheriting their preferences which are uncompromisable at all, period.
- IME-Developer-implemented Shift-key alphanumerical mode toggle can provide a fast way of inputting ASCII alphanumerals without moving the pinkle finger away from the Shift key.
-
Provide a USABLE way of showing a description text at the bottom of the IMKCandidate window. This feature can be used for telling users what this candidate window is prepared for.
-
Official TouchBar IMKCandidates API for 3rd-party input method developers.
-
IMKCandidate window instances need to be separated for each InputMethodController. Reason: The IMKController session of an app sometimes deactivates after the one of the another client app gets activated, leading to the mess of handling input states. Imagine that you switched to another app and immediately want to call the symbol menu (shown through IMKCandidates), but the symbol menu window gets disappeared due to deactivateServer() triggered by another client app.
-
Please state clearly in the documentation of certain APIs (like
(de)activateServer()
andsetValue()
) if they are expected to be mission-critical (e.g. expected to finish their processings as fast as possible). Otherwise, this can cause responsiveness issues of an input method if it is using Swift and is not using Grand Central Dispatch. -
An official workable solution (with precise sample project) demonstrating how to implement the IME settings pane of the System Preferences / Settings window:
Additional notes: Since macOS 10.14 till now, in order to use IMKCandidates, these following APIs have to be exposed through bridging-header:
@interface IMKCandidates(PROJECT_TARGET_NAME) {}
- (unsigned long long)windowLevel API_AVAILABLE(macosx(10.14));
- (void)setWindowLevel:(unsigned long long)level API_AVAILABLE(macosx(10.14));
- (BOOL)handleKeyboardEvent:(NSEvent *)event API_AVAILABLE(macosx(10.14));
- (void)setFontSize:(double)fontSize API_AVAILABLE(macosx(10.14));
@end
Finally, please allow input methods sellable on Mac App Store. A macOS input method app can be installed in the ~/Library/Input Methods/ and is okay to be Sandboxed (e.g. vChewing since v2.3.0). Therefore, there should be no privacy concerns anymore.
November 2022 Apple Office Hour
该怎样让 InputMethodKit 内建的选字窗在「不用 bridging header 强制曝露内部 API (set)WindowLevel」的前提下「不被 NSMenu 与 Spotlight 选字窗挡住」?
该怎样让 InputMethodKit 内建的选字窗在「不用 bridging header 强制曝露内部 API handleKeyboardEvent()」的前提下响应使用者的 NSEvent 键盘事件输入?
该怎样让 InputMethodKit 内建的选字窗在「不用 bridging header 强制曝露内部 API handleKeyboardEvent()」的前提修改选字窗的文字尺寸?
想明确了解下 Apple 接下来打算怎样对付这个千疮百孔且严重缺乏 Documentation 与单元测试的 InputMethodKit。好像 annotation 的方法都还是失效的。
该怎样让不同的 IMKInputController 副本(Instances)各自管辖的 IMKCandidates 副本在「是否显示」这方面的行为「不出现跨副本干涉」的情况?举例:被切换出去的 App 可能会在当前的新 App activateServer() 之后才会 deactivateServer(),然后会干扰到新的 App 的选字窗显示(会突然隐藏掉,但新的 App 的输入法的状态还在文字输入状态,就会鬼打墙)。
第三方输入法该怎样在输入法选单当中隐藏「macOS 内建的『编辑使用者辞典』」这种非常具有迷惑性的选单项?使用者可能会以为这个选项可以用来编辑第三方输入法的辞典。如果不打算对第三方开发者开放对 macOS 系统偏好设定内的输入法辞典资料的存取的话,请考虑让 macOS 针对所有第三方输入法都隐藏这个选项。