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
|
[xkb-boshiamy]
Hack to implement Boshiamy Input Method using only userspace X11 config files
------------------------------------=[Setup]=-----------------------------------
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
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 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.
|
