1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
|
[xkb-boshiamy]
Hack to implement Boshiamy Input Method using only userspace 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/
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)
--------------------------------=[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 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 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:
<U516B> <U5357> <U516B> <U516B> <space> : "肏"
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 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. 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.
-------------------------------=[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
|
