[xkb-boshiamy] Hack to implement Boshiamy Input Method using only X11 config files ------------------------------------=[Setup]=----------------------------------- Move "XCompose" to ~/.XCompose (Or append if you already have custome XCompose rules) Move "boshiamy" to /usr/share/X11/xkb/symbols/ note: you might have to do this again whenever you update xkb Append "startup" to your wm's X11 startup script. Alternatively you can simply set boshiamy as one of your keyboard layouts somewhere in your X11 Configs (see further reading) NOTE: If you're using a real input method like Ibus or fcitx You need to click "use system keyboard layout" in settings. See the Archlinx Wiki link below --------------------------------=[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 application side (on Wayland via libxkbcommon). I have hijacked this functionality to implement a fully functional version of the Boshiamy input method that requires no software other than X11, and which should be in theory compatible with any X11 application unlike ibus or fcitx. Background]=--- What is a compose/dead key? Certain keyboard layouts allow for diacritics to be added to letters via "dead key". For the user this means pressing the diacritic key followed by the base letter. For example, to type "ô" on the German layout you would press the "^" key followed by "o". The "^" is called a "dead key". For those curious, you type "^" by itself by pressing the key twice. Compose is a similar functionality except is relies on pressing a predefined "compose" key followed by a sequence of other keys. For example AltGr+e+= types the euro sign "€". In X11's case, this is all defined via a config file in /usr/share/X11/locale/$LOCALE/Compose. For reference, the Compose file for en_US.UTF-8 is 5000 lines long, which is on the order of magnitude of your average Chinese input method. This functionality can also be user defined at ~/.XCompose How exactly is this functionality being handled by X11? When a key is pressed, X11 sends a key event containing "key symbols" to the application. This includes printable ascii characters like "a" or "@" but it can also be keys like "prsc" (printscreen) or non ascii characters like "Г" or "肏". The specifics of how physical keys get turned into key symbols are defined in /usr/lib/X11/xkb/. Compose happens at one layer of abstraction above "key symbols". Most applications after receiving an X11 key event, use libxkbcommon/xlib to translate this into a string, during which the Compose table is referenced to get the desired result of the compose sequences. Boshiamy Implementation]=--- 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 compose rules that map the sequences of the above mentioned key symbols plus space or a number key to various characters. For example: : "肏" maps b+b+n+b+space to "肏" Startup runs setxkbmap so that both the us (you can change this to whatever layout you use) and boshiamy layout are 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 the XCompose file would be needed. ----------------------------------=[Questions]=--------------------------------- Will this method 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 rely 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. 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. Is it possible to make this 100% user specific? It seems that although modern Wayland based systems have a way of handling user specific keyboard layouts, every option I've tried on my system to make the keyboard layout user specific like the XCompose file has not worked. -------------------------------=[Further Reading]=------------------------------ man xkeyboard-config(7) for more setxkbmap options man xcompose(3) for how .XCompose works https://www.x.org/archive/X11R7.5/doc/input/XKB-Config.html for xkb layout config https://www.x.org/archive/X11R7.5/doc/input/XKB-Enhancing.html for a description of the xkb layout system https://festina-lente-productions.com/articles/the-compose-key/ for how the Compose system is supposed to be used https://wiki.archlinux.org/title/X_keyboard_extension for comprehensive information on how xkb works and how to configure it