NumberInput_IMKit_Sample Input Method Kit (IMKit) Apple Radars and Bug Reports

Opening this issue to collect Radars that have been opened about the Mac OS X Input Method Kit framework.

https://developer.apple.com/documentation/inputmethodkit

Please open bugs on Radar and Open Radar, and post links in this ticket:

https://bugreport.apple.com/

https://openradar.appspot.com/

Input Method Kit tag on Stack Overflow:

https://stackoverflow.com/questions/tagged/input-method-kit

Mar 24 '18 20:03 pkamb

Input Method Kit reports wrong values for NSEvent charactersIgnoringModifiers in handleEvent:client: https://openradar.appspot.com/radar?id=21463962 rdar://21463962

Input Method Kit cannot catch NSKeyUp events. Chorded keyboards are thus impossible to implement. https://openradar.appspot.com/radar?id=5041331931971584 rdar://21376535

IMKCandidates setCandidateData: method not working in place of IMKInputController candidates: delegate method https://openradar.appspot.com/radar?id=4960397434028032 rdar://26868067 https://twitter.com/mzp/status/918263309605920769 https://github.com/mzp/NumberInput_IMKit_Sample/commit/0be199ee56652278cbe3c17058bf235b86f70a65

Custom input method app is added to Keyboard Input selector hundreds of times. [NumberInput sample code] https://openradar.appspot.com/radar?id=5022901556215808 rdar://21376114 https://twitter.com/mzp/status/922610216599830528 image: https://imgur.com/a/mxMCtVA

Add documentation that .inputmethod. is required(?) in the bundle identifier of an Input Method Kit input method. https://openradar.appspot.com/radar?id=5033563544092672 rdar://21376022

Mar 24 '18 20:03 pkamb

Here are two related Radars for non-IMKit mouse and keyboard handling:

Unable to get position of text-insertion caret from AX when no text is selected https://openradar.appspot.com/radar?id=5026746088816640 rdar://14285519

Returning NULL in CGEventCallback function does not kill mouse events https://openradar.appspot.com/radar?id=5511730692096000 rdar://14123633

Mar 24 '18 20:03 pkamb

Some methods of IMKCandidates don't work well.

Mar 25 '18 10:03 mzp

IMK has some private features(and I want to use it)

Some properties of Info.plist is unknown where to use:

Other:

Apr 12 '18 22:04 mzp

IMKServerInput crashes under ARC when super used for -updateComposition and -cancelComposition. Fixed by overriding methods or perhaps by overriding selectionRange.
rdar: not written yet

https://github.com/stackia/XIME/blob/master/XIME/Source/InputController.m https://github.com/pkamb/InputMethodKitBoilerplate/commit/d69a16387caf9637f9549cc33f7c4218ee866420

Jul 28 '18 01:07 pkamb

Suggestion from Apple engineer at WWDC for developing Input methods:

Move Input Method executable into the Library/Input Methods/ directory via a Run Script build phase on your Xcode project:

    echo "Moving Input Method Kit app to Input Methods directory."
    killall $EXECUTABLE_NAME
    cp -R "$BUILT_PRODUCTS_DIR/$FULL_PRODUCT_NAME" "$HOME/Library/Input Methods"
    #"$HOME/Library/Input Methods/$EXECUTABLE_FOLDER_PATH/$EXECUTABLE_NAME" install;

Log in to a fresh OS X user account after installing the input method. Use this account to test the Input Method.
Remove the IMKit caches if needed. Other caches are found in the Sandbox container of each Input Method.

    /System/Library/Caches com.apple.IntDataCache.le*

    sudo find/private/vare/folders/ -name "com.apple.IntlDataCache"

Jul 28 '18 02:07 pkamb

Logging I was made aware of during a WWDC 2016 lab; not quite sure of the intended behavior but perhaps useful to others:

 defaults write -g IMKClientServerXPCTracing 1

Jul 30 '18 22:07 pkamb

[FB11300759] IMKCandidates (of InputMethodKit) has lack of hardened unit tests.

There are too many bugs of IMKCandidates complained and reported in the recent decade, but it looks like Apple is not dealing with them case-by-case. That's why I feel that sending bug reports one-by-one is not helpful at all in improving the overall experience of IMKCandidates.

https://github.com/pkamb/NumberInput_IMKit_Sample/issues

Conclusion first: All APIs officially exposed in the InputMethodKit shall be hardened by strong and well-designed unit tests in order to make sure that they are fully functional, plus nutrient documentations. Also, I believe that there are new IMKCandidates APIs you want to expose to the 3rd-party developers.

I think that the following things are urgent:

All font attributes (incl. font size attributes and langIdentifier attributes) and attachments generated by { InputMethodController.candidates(_ sender: Any!) -> [Any]! } are expected to be reflected in the IMKCandidates panel, and are also expected to be delivered intact as parameters sent to { InputMethodController.candidateSelectionChanged(_ candidateString: NSAttributedString!) } and { InputMethodController.candidateSelected(_ candidateString: NSAttributedString!) }
There needs to be a public, swift-friendly API to know the highlighted candidate index of the current candidate panel (or send it as a new parameter to { InputMethodController.candidateSelectionChanged() }. Currently, the identifiers (I dunno whether it is the index) sent back by { selectedCandidate() -> Int } are always NSNotFound.
Also allow setting selection keys with characters.
There needs to be a new way of interacting with IMKCandidates by not sending NSEvents to it but instead telling it to do specific things (like flipping pages, moving highlight to specific candidate index, expand the horizontal grid list, etc.)
Make default candidate keys responsive by exposing { IMKCandidates.perform(Selector(("handleKeyboardEvent:")), with: NSEvent) } to 3rd-party developers, and please document this function well. Currently, IMKCandidates.interpretKeyEvents() is not handling candidate keys at all (so does IMKCandidates.handle(event:)).
Please Stop hiding the IMKCandidates beneath NSMenus and Spotlight window by default. At least, I have tried dealing with this by using { IMKCandidates.perform(Selector(("setWindowLevel:")), with: client().windowLevel() + 1000) }, with a miserable result that the candidate runs behind all windows of the current desktop instead: as long as the input method gets process-killed, it happens and you have to reboot macOS to let the IMKCandidates window shown above the client.

Conclusion:

Finally, this report consists of angers and desperations from almost all 3rd-party input method developers for macOS in this decade. Please don't ask me to provide a sample project to expose this. I am not paid by Apple to help you write these unit tests. If you want a sample project, feel free to check vChewing: https://github.com/ShikiSuen/vChewing-macOS (please run make update and compile the target "vChewingInstaller"). Note that this vChewing project is only documentated in Traditional Chinese, regardless that it has UI language support in English and Japanese. You can enable IMK candidate window through the DevZone page in vChewing Preferences window.

P.S.: A powerpoint presentation file written in Traditional Chinese tells how vChewing implemented the IMKCandidates, plus my complaints about its real issues, for your reference: https://docs.google.com/presentation/d/1hYO8U_V4UNQb9PT1K_yzZS_hpzzLCQ_c2GhnoEo8f6s/

Aug 18 '22 10:08 ShikiSuen

Note: The API setSelectionKeys() is not wrecked but has a hard prerequisite:

Run IMKCandidates().setSelectionKeysKeylayout() first.

Otherwise, setSelectionKeys() won't work.

Apr 05 '24 12:04 ShikiSuen