Kindle DX 的酷音中文輸入法 (2)
Posted by tjwei on 星期一, 8月 15, 2011 with 3 comments
(上接 Kindle DX 的酷音中文輸入法 )
(更新** GitHub 專案 https://github.com/tjwei/KindleChewing )
檔案 Source and Binary 在此 目前預設是使用許氏鍵盤,可用 Sym 切換漢語拼音。我沒有包入普通的注音鍵盤,因為 kindle 上面數字鍵比較不好打,而且鍵盤上沒有標注音符號。普通的注音輸入法,沒有特別不能用的理由,但雖然 alt-q alt-w 的方式,可以正確輸入 1,2 等等數字,但 . < ; - 這些鍵不能直接輸入,所以還是有些音打不出來,需要用其它鍵代替。
更新:
(更新** GitHub 專案 https://github.com/tjwei/KindleChewing )
檔案 Source and Binary 在此 目前預設是使用許氏鍵盤,可用 Sym 切換漢語拼音。我沒有包入普通的注音鍵盤,因為 kindle 上面數字鍵比較不好打,而且鍵盤上沒有標注音符號。普通的注音輸入法,沒有特別不能用的理由,但雖然 alt-q alt-w 的方式,可以正確輸入 1,2 等等數字,但 . < ; - 這些鍵不能直接輸入,所以還是有些音打不出來,需要用其它鍵代替。
更新:
- 修改 post key event 的方式,讓一些 kindlet 也能使用。
- 簡單的處理了螢幕旋轉的狀況。
- 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。
- 假扮 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 前面。
- khk 可用,msp 就不能用了。當然,其實可以修改 msp 程式碼,讓 msp.g 載入我們的程式碼之後,繼續他原來的功能。但這樣就失去這種方式的意義了。這個輸入法的優點就是不用修改主程式碼。
- 這版的 khk 用到了 AppContextBridge 這個(隱藏?)功能。不然我不知道怎麼送 keyEvent 到 kinlet 中。
- im 參考了 launchpad 和 kiterm 。不過修改了很多地方,可能只剩下(沒用到的) daemonize,還有 screen 和 pixop。
- khk 是用 eclipse 然後包進所有的 kindle jar 用 cdc 1.0 模式編譯。
- 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++ 也不見得總是會有問題。
- 原本想試試看加入 google 語音輸入,但錄了辦天才發現 dx 沒有辦法錄音。kindle 3 才行。不過錄音的時候,也不會產生錯誤訊息,只是沒有聲音而已。 原則上,khk 配合 curl, 和 flac 即可達到語音輸入的功能。kindle 內的 busybox wget 似乎無法送出客製化 header,不然連 curl 也不需要。
- freetype的用法 是參考 freetype 的教程和這篇。
- DBus 的使用方式是參考這篇。 雖然 glib 裡面有 dbus 支援,但是 kindle dx 的 glib 太舊,所以只好用 C API了。
- CanBeFound 的方式是修改 SymbolPopup 的方式來處理。這是一個好的方法。事實上,我的第一個想法也是如此,畢竟 symbol popup 是 kindle 裡面長得最像輸入法的東西,其實這也是我之前弄磚 kindle 的原因。 慘的是磚了之後才發現已經有人完成這個想法。
- 我的方式的最大優點是,source 可以公開。因為完全不用修改 kindle 的程式碼。
- 第二個優點是使用 D-Bus 做訊息溝通。所以其他程式只要寫個 D-Bus 處理器就能使用。而且對於 kindle framework 的依賴可能比較小一點。
- kindle 裡面的程式,可以選擇輸入時不使用 symbol popup。這時,symbol popup based 方式就無效。比方 kindle 的 home 介面,你可以直接叫出酷音輸入文字,然後搜尋框就會跑出來。Sym 鍵則是要在搜尋框出來後,才能叫出 SymbolPopup。
- 但除此之外,都是 CanBeFound 使用 SymbolPopup 的方式比較直接比較好。
- 大部分輸入文字的地方,如果程式師不特地亂搞,照規矩來,其實都可以叫出 SymbolPopup。所以第 4 點沒有太大意義。
- SymbolPopup 可以很容易編譯。msp 比較麻煩一點。其實也可以把 DBus 處理的部份讓 SymbolPopup 來啟動。但主要的考量是能否公開程式碼的問題。
- 使用 SymbolPopup 的優點是簡潔。kindle 裡面的 eventqueue 不只一條,至少 msp.g 能抓到的那條,無法處理 kindlet 的訊息。所以我必須要用到 AppContextBridge 來跨越 context 送訊息。看起來似乎不太腳踏實地,也增加了對於 kindle framework 的依賴。而 SymbolPopup 的好處是,程式需要符號輸入時,會自己去把你叫出來,這就不用擔心什麼 context, thread group 什麼的問題了。
- SymbolPopup 因為在 Kindle 的框架內,所以不用擔心旋轉顯示的問題,也能在適當的位置顯示。我的外掛的方式,因為有個內奸在裡面,所以某種程度上也能整合的不錯,但比較累。
- CanBeFound 的輸入法可以在 browser 內輸入,但是我的 dx 沒辦法。我想應該是 browser 的問題。因為我也有讓 symbol popup 輸入中文字的測試程式,但是在 dx 的 browser 裡面,只有符號能輸入,中文不行。不過問題是我的外掛輸入法在 dx 的 browser 裡,連英文也無法輸入,這點我就不太清楚為什麼了。
Categories: kindle
3 意見:
辛苦了!期待browser也可以使用的那一天,拼音畢竟還是沒有注音習慣。我也想試試進去改些東西,如果可以弄出個ssh client的話就可以用它遠端遙控Server了XD
我覺得 KindleTerm 還不錯,只是不支援中文。不過稍加修改,應該就能弄中文了。
很高興能看到有許氏鍵盤的愛用者。
張貼留言