Kindle DX 的酷音中文輸入法 (2)

（上接 Kindle DX 的酷音中文輸入法 ）
(更新** GitHub 專案 https://github.com/tjwei/KindleChewing )
檔案 Source and Binary 在此 目前預設是使用許氏鍵盤，可用 Sym 切換漢語拼音。我沒有包入普通的注音鍵盤，因為 kindle 上面數字鍵比較不好打，而且鍵盤上沒有標注音符號。普通的注音輸入法，沒有特別不能用的理由，但雖然 alt-q alt-w 的方式，可以正確輸入 1,2 等等數字，但 . < ; - 這些鍵不能直接輸入，所以還是有些音打不出來，需要用其它鍵代替。
更新：

• 修改 post key event 的方式，讓一些 kindlet 也能使用。
• 簡單的處理了螢幕旋轉的狀況。

原理說明：

1. khk.jar 是一個假的 msp.jar。msp.jar 就是 kindle 裡面的採地雷/五子棋小遊戲。Kindle 會在使用者介面啟動時，載入 msp.g 這個 class。msp 大致上還能猜出跟 Mine Sweeper 之間的關聯，但是一個 class 叫 g 就有點怪。不過這是由於 kindle 的程式碼被弄亂過得原因。總之，這個是寫死的。這個 class 不能叫做 msp.h, msp.g2, msp.gg, msp2.g，就只能叫做 msp.g，不然 kindle 主程式不會主動過來招呼你的，因為跟你不熟。當然你也可以假裝成為其他 kindle 認識的人，比方說像是 browser, pictureviewer, pdfreader, mobireader 之類的，甚至是 home，但比較起來，採地雷看起來最人畜無害，所以選擇假扮 msp。
2. 假扮 msp 的方式參考 http://www.mobileread.com/forums/showthread.php?t=61093 ，但只有精神上類似，因為 kindle 內部改了很多。不用完全模仿 msp 的格式，任何 class 都行。只要記得把 meta info 包進去就行了。反正重點只是要讓 kindle 呼叫 g() 這個constructor。名稱叫 khk 的原因是要搶在 msp.jar 之前載入，先搶先贏。如果你叫做 msp2.jar，就只能繼續玩踩地雷了。不過這算是不太保險的 hack。因為沒有人保證 khk.jar 一定會在 msp.jar 前面載入。完全只是因為 kindle 啟動 script 裡面的 booklet/*.jar 造成 cvm 的 command option 中， khk 會比 msp 前面。
3. khk 可用，msp 就不能用了。當然，其實可以修改 msp 程式碼，讓 msp.g 載入我們的程式碼之後，繼續他原來的功能。但這樣就失去這種方式的意義了。這個輸入法的優點就是不用修改主程式碼。
4. 這版的 khk 用到了 AppContextBridge 這個(隱藏？)功能。不然我不知道怎麼送 keyEvent 到 kinlet 中。
5. im 參考了 launchpad 和 kiterm 。不過修改了很多地方，可能只剩下(沒用到的) daemonize，還有 screen 和 pixop。
6. khk 是用 eclipse 然後包進所有的 kindle jar 用 cdc 1.0 模式編譯。
7. im 是用 scratchbox 編譯。kindle dx 的 libstdc++ 分常舊，雖然網路上面常常看到推薦的 toolchain 是 scratchbox-toolchain-cs2007q3-glibc2.5-*，但裡面的 libstdc++.so 是 6.0.9，而 kindle 是 6.0.8，不要看這 8 和 9 差不多，這可能會造成一些 c++ 的程式發生 version `GLIBCXX_3.4.9' not found 錯誤。所以我用 scratchbox-toolchain-arm-linux-2006q3。如果不用 c++ 的話，似乎是沒什麼問題。用 c++ 也不見得總是會有問題。
8. 原本想試試看加入 google 語音輸入，但錄了辦天才發現 dx 沒有辦法錄音。kindle 3 才行。不過錄音的時候，也不會產生錯誤訊息，只是沒有聲音而已。 原則上，khk 配合 curl, 和 flac 即可達到語音輸入的功能。kindle 內的 busybox wget 似乎無法送出客製化 header，不然連 curl 也不需要。
9. freetype的用法 是參考 freetype 的教程和這篇。
10. DBus 的使用方式是參考這篇。 雖然 glib 裡面有 dbus 支援，但是 kindle dx 的 glib 太舊，所以只好用 C API了。

與 CanBeFound 的 kindle 3 的中文輸入法 的比較：

1. CanBeFound 的方式是修改 SymbolPopup 的方式來處理。這是一個好的方法。事實上，我的第一個想法也是如此，畢竟 symbol popup 是 kindle 裡面長得最像輸入法的東西，其實這也是我之前弄磚 kindle 的原因。 慘的是磚了之後才發現已經有人完成這個想法。
2. 我的方式的最大優點是，source 可以公開。因為完全不用修改 kindle 的程式碼。 
3. 第二個優點是使用 D-Bus 做訊息溝通。所以其他程式只要寫個 D-Bus 處理器就能使用。而且對於 kindle framework 的依賴可能比較小一點。
4. kindle 裡面的程式，可以選擇輸入時不使用 symbol popup。這時，symbol popup based 方式就無效。比方 kindle 的 home 介面，你可以直接叫出酷音輸入文字，然後搜尋框就會跑出來。Sym 鍵則是要在搜尋框出來後，才能叫出 SymbolPopup。
5. 但除此之外，都是 CanBeFound 使用 SymbolPopup 的方式比較直接比較好。
6. 大部分輸入文字的地方，如果程式師不特地亂搞，照規矩來，其實都可以叫出 SymbolPopup。所以第 4 點沒有太大意義。
7. SymbolPopup 可以很容易編譯。msp 比較麻煩一點。其實也可以把 DBus 處理的部份讓 SymbolPopup  來啟動。但主要的考量是能否公開程式碼的問題。
8. 使用 SymbolPopup 的優點是簡潔。kindle 裡面的 eventqueue 不只一條，至少 msp.g 能抓到的那條，無法處理 kindlet 的訊息。所以我必須要用到 AppContextBridge 來跨越 context 送訊息。看起來似乎不太腳踏實地，也增加了對於 kindle framework 的依賴。而 SymbolPopup 的好處是，程式需要符號輸入時，會自己去把你叫出來，這就不用擔心什麼 context, thread group 什麼的問題了。
9. SymbolPopup 因為在 Kindle 的框架內，所以不用擔心旋轉顯示的問題，也能在適當的位置顯示。我的外掛的方式，因為有個內奸在裡面，所以某種程度上也能整合的不錯，但比較累。
10. CanBeFound 的輸入法可以在 browser 內輸入，但是我的 dx 沒辦法。我想應該是 browser 的問題。因為我也有讓 symbol popup 輸入中文字的測試程式，但是在 dx 的 browser 裡面，只有符號能輸入，中文不行。不過問題是我的外掛輸入法在 dx 的 browser 裡，連英文也無法輸入，這點我就不太清楚為什麼了。