Added README

1 files changed, 43 insertions, 4 deletions

diff --git a/README b/README
index c2e0361..ae12129 100644
--- a/README
+++ b/README
@@ -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.