diff options
Diffstat (limited to 'README')
| -rw-r--r-- | README | 47 |
1 files changed, 43 insertions, 4 deletions
@@ -1,7 +1,11 @@ [xkb-boshiamy] -Hack to implement Boshiamy Input Method using only X11 config files +Hack to implement Boshiamy Input Method using only userspace X11 config files + ------------------------------------=[Setup]=----------------------------------- -Move +Move XCompose to ~/.XCompose +Move boshiamy to /usr/share/X11/xkb/symbols/ +run startup, or append it to your wm's X11 startup script. + --------------------------------=[How it Works]=-------------------------------- X11 handles key inputs via the xkb extension, which in addition to defining keymaps/layouts, also handles compose/dead keys on the @@ -42,7 +46,42 @@ How exactly is this functionality being handled by X11? translate this into a string, during which the Compose table is referenced to get the desired result of the compose sequences. + Boshiamy Implementation]=--- -First, I did some regex wrangling to create a Compose file that defines every -character on my computer's copy of Boshiamy +the "boshiamy" file defines a keyboard layout named "boshiamy" where the QWERTY +keys are mapped to key symbols corresponding to the one key abbreviation of that +key in Boshiamy. (These key symbols can be arbitrary as long as they don't +exist in any other key layout) For example the "Q" key on US Keyboards is mapped +to key symbol "U9AD8" (高). + +The XCompose file defines a compose rule where the key sequence <U9AD8> <space> +outputs the string "高". + +Startup runs setxkbmap so that both the us (you can change this to whatever +layout you use) and boshiamy are both loaded and toggled with the alt key. + +One issue with this implementation is that Compose rules are independent of the +keyboard layout (which is why the en_US.UTF-8 Compose file is so large, it has +to handle essentially every keyboard layout), which means the only way to switch +between boshiamy and regular ascii input is to define a new keyboard layout that +only types its own key symbols, otherwise only XCompose would be needed. + +----------------------------------=[Questions]=--------------------------------- +Will this work with other input methods? + With the custom key symbols I think CangJie is honestly a better + candidate. Any component based input method will work since they are + more or less open loop. Inferior phonetic input methods like Pinyin and + Zhuyin which requires the user to pick out the character and which + relies on predictive text can not be implemented in this way. + +Is This Slow? + It takes 2-3 seconds to load the compose file on X11 startup. Honestly + not nearly as bad as I expected and a lot faster than ibus. + +Does this work with xyz program? + This should work with virtually any X11 program that properly implements + text input and which you can type. This doesn't work on the Linux + console, which uses its own keymap configs. Unfortunately kmscon, even + though it uses xkb, gets string information one key at a time and + therefore does not implement compose functionality properly. |