提案：重啟Windows版新酷音計畫

[PCMan]

Hi,
我沒參加 win32-chewing 開發已經很久了，
不過 Windows 的新注音輸入法實在太難用，
前陣子看到許多有心的朋友在研究 text service
加上最近又看到歪林輸入法釋出新範例
不禁讓人有點想重新啟動 windows 版新酷音
目前主要需要克服的困難如下：
1. Windows 8 禁用傳統 IME，勢必要用 COM/Text service 重寫，砍掉重練
2. Windows 8 在 app 內使用 IME，禁用 IPC，也就是說，現有 client/server 架構完全不能用，要砍掉重練
3. 設定值不能透過 registry 共用，要砍掉重練

我個人的想法是：
1. 以歪林輸入法，或現有的日文 tex service 實作為骨架
2. 不一定要用純 COM，用 ATL 來寫會比直接用 COM 好寫一點，UI 也可用 ATL/WTL (可惜ATL 不是
free，但是某版的 Win SDK 有免費附舊版 ATL)

不能用IPC 的問題，研究後有兩個解法:
1. 用 libchewing 的 sqlite branch，把所有偏好設定和詞庫放進 sqlite，然後把 sqlite db 檔放入
shared folder，這樣所有 IME instance 都可以讀寫，就可繞過 IPC問題，這應該是比較簡單快速的方法
2. 用 local web service 來實作 web server，在 text service dll 內與之連線。這是 MS
官方建議的做法，不好寫，不方便，很多此一舉，但 web server 我想可用 node.js 快速實作，但開發起來還是有一定難度

這裡有不錯的參考資料：
http://msdn.microsoft.com/en-us/library/windows/apps/hh967425.aspx
http://software.intel.com/en-us/articles/strategies-for-app-communication-between-windows-8-ui-and-windows-8-desktop

問問看有沒有朋友有興趣一起研究
又古時候我記得 chewing 有 sqlite branch，由 gugod 開發，在 OpenVanilla 用過
不知道後來如何了？

Thanks!

[Jui-Wen Hsu]

Hi, PCMan 長輩好:

關於ATL問題，我有正式版的Windows 授權，或許可以幫得上忙 :P.

PCMan於 2013年8月31日星期六UTC+8下午10時06分02秒寫道：

[PCMan]

2013/8/31 PCMan <pcma...@gmail.com>:

晚上我又仔細想了一下，
其實我們或許不需要 IPC
靜態系統辭庫的部分是用 mmap 讀取，不會寫入
基本上沒 sync 也不會怎樣
唯一會發生問題是在升級的時候，更新詞庫會 crash
因為 mmap 使用中的檔案遭到替換，會有無法預期的狀況
所以只能重開機才能更新辭庫
除這個缺點外，在各個 IME dll 裡面同時 mmap 讀取是沒問題的
有問題的只有使用者辭庫 hash.dat
使用者辭庫如果做好適當的 file locking
控制每次只有一個 process 讀寫，
事實上也可以用 mmap 操作，也不需要 server/client 架構
當然 file locking 效率不佳，但至少這能 work
否則在 windows 8 metro 幾乎不提供任何 IPC 機制給 app 的情況下
似乎沒有更好的辦法了。
如果hash.dat這部分可以加上適當的 locking，應該就能用了
而且同時寫入應該是極其罕見的狀況，
畢竟輸入法一次只能有一個 instance 取得輸入焦點
應該幾乎不會兩個 instance 同時在更新使用者詞頻才對
看來是可以用目前 czchen 已經完成的部分來實驗看看!

[Tib]

http://msdn.microsoft.com/en-us/library/windows/apps/hh967425.aspx

mmap 都不見得可以用, 使用者詞庫大概要用 web service (還要 app 有開相關權限) XD

2013/9/1 PCMan <pcma...@gmail.com>

--
您已訂閱「Google 網上論壇」的「Chewing IM Development」群組，因此我們特別傳送這封郵件通知您。
如要取消訂閱這個群組並停止接收來自這個群組的郵件，請傳送電子郵件到 chewing-deve...@googlegroups.com。
如要在此群組張貼留言，請傳送電子郵件至 chewin...@googlegroups.com。
請前往以下網址造訪這個群組：http://groups.google.com/group/chewing-devel。
如需更多選項，請前往：https://groups.google.com/groups/opt_out。

[PCMan]

我覺得應該要可以用才對，還沒實驗過，
但是文件是這樣寫
"Dictionary Files Frequently, IMEs have read-only dictionary files
to map user input to specific characters. To access these files from
inside an app container, your IME must place them under the Program
Files or Windows directories. By default, these directories can be
read from an app container, so IMEs can access dictionary files that
are stored in these locations. If your IME must store the dictionary
file somewhere else, it must explicitly manipulate the Access Control
Lists (ACL) of the dictionary files to allow access from app
containers."

另外，我第一封信列的 reference 有整理可用的機制：
http://software.intel.com/en-us/articles/strategies-for-app-communication-between-windows-8-ui-and-windows-8-desktop
請看最底部的 Summary of Viable Approaches，有整理

Thanks!

2013/9/1 Tib <tiberi...@gmail.com>:

[ChangZhuo Chen]

Hi All,

- 我先在 chewing 開了 repository 來存這些 references [1]，如果有其他資料也幫忙 update 一下。

- TSF 的部份我可以幫忙重寫一個避免 license issue，不過之前只改過 COM 的，如果要用 ATL/WTL 需要再研究一下。

[1] https://github.com/chewing/windows-TSF-chewing

[PCMan]

2013/9/1 ChangZhuo Chen <czc...@gmail.com>:

> Hi All,
>
> - 我先在 chewing 開了 repository 來存這些 references [1]，如果有其他資料也幫忙 update 一下。
>
> - TSF 的部份我可以幫忙重寫一個避免 license issue，不過之前只改過 COM 的，如果要用 ATL/WTL 需要再研究一下。

基本上，M$ 釋出的 sample code 是以 MS-LPL 授權
這是可以免費使用但是 non-free 的 license，加諸不少限制
也不符合 OSI or FSF 的要求，
改作出衍生著作合法，但是無法變成 free software
libchewing 是 LGPL，如果改成動態聯結，基本上沒問題

如果要快點可以用，過渡的方法是，
TSF-chewing 先維持 MS-LDL 授權，改為動態連結 libchewing
等各部分都重寫完畢，沒有 MS 的 code 的時候，relicense成 LGPL
不過MS的code架構和coding convention都不討喜，重寫也無妨

你的 proof of concept 我已經測試成功了，Windows 7, 64bit
問題出在 regsvr32 需要用系統管理員權限呼叫，否則無法寫入 registry
我改用 administrator 就搞定了，初步看起來很不賴!! 可打中文也能選字

至於要 pure WinAPI & C++，還是要 ATL，各有優缺
ATL 沒有免費版，且只能支援 VC++
但是偷吃步是最新版 Windows driver kit (WDK) 內附
精簡版的 ATL 7，據說基本上可用 (但是新版WDK已經移除ATL)
另 Windows SDK 2003 有含 ATL 3.0 (但是新版 SDK 已經移除ATL)
並且 ATL 3.0 會有資料執行防止的問題，需要 patch 幾行 code (但我有patch)

但使用ATL的好處是，有很多方便的 class
CComPtr: 會自動 AddRef/Release 的 COM smart pointer
CComBStr: 方便使用的 BSTR wrapper class
CComObjectRoot: 方便實作 COM 物件，內建預設 QueryInterface 實作，
可支援 interface map, sink map等等方便的機制，
比起噁心的手寫純COM要好
並且還有提供許多 Windows API 的C++ wrapper，建圖形介面方便
更可以和free 的WTL搭配使用，會更好用(我沒實際用過)

使用純 C++ 直接寫 COM，下場就是大量冗餘重複噁心的code
就像是用 glib / GObject 寫物件導向一樣的感覺
還是做得到，但是不舒服，code 也不好讀

不知道大家覺得如何？

> [1] https://github.com/chewing/windows-TSF-chewing

[PCMan]

還是直接寫COM好了，現成的範例全是純COM，反而沒ATL的
硬要改寫成ATL反而花力氣。
只要小心封裝，把COM 的 code 鎖死在自己的 module 裡面
其他部分是不會摸到COM的，應該還好
剛查了 corvus-skk 程式碼，看來其實有偷用 MS 的 sample code
相似度實在太高，而且沒有 copyright notice
這樣理論上是不合 MS-LPL 授權的...
我相信，Base on corvus-skk 的 code 的話，
基本上也會偷用到 MS 的code，
可能還是自己重寫比較好，也比較乾淨

順便提交一個 patch
附件的 patch 修復在 Windows 7以下版本不能 build 的問題

Thanks!

2013/9/1 PCMan <pcma...@gmail.com>:

[ChangZhuo Chen]

On Sunday, September 1, 2013 7:52:31 PM UTC+8, PCMan wrote:

還是直接寫COM好了，現成的範例全是純COM，反而沒ATL的
硬要改寫成ATL反而花力氣。
只要小心封裝，把COM 的 code 鎖死在自己的 module 裡面
其他部分是不會摸到COM的，應該還好
剛查了 corvus-skk 程式碼，看來其實有偷用 MS 的 sample code
相似度實在太高，而且沒有 copyright notice
這樣理論上是不合 MS-LPL 授權的...
我相信，Base on corvus-skk 的 code 的話，
基本上也會偷用到 MS 的code，
可能還是自己重寫比較好，也比較乾淨

我先重寫這部分，先有個可以動的 code 再看看要怎麼弄

順便提交一個 patch
附件的 patch 修復在 Windows 7以下版本不能 build 的問題

Thanks!

Thank for the patch.

[PCMan]

2013/9/1 ChangZhuo Chen <czc...@gmail.com>:

> On Sunday, September 1, 2013 7:52:31 PM UTC+8, PCMan wrote:
>>
>> 還是直接寫COM好了，現成的範例全是純COM，反而沒ATL的
>> 硬要改寫成ATL反而花力氣。
>> 只要小心封裝，把COM 的 code 鎖死在自己的 module 裡面
>> 其他部分是不會摸到COM的，應該還好
>> 剛查了 corvus-skk 程式碼，看來其實有偷用 MS 的 sample code
>> 相似度實在太高，而且沒有 copyright notice
>> 這樣理論上是不合 MS-LPL 授權的...
>> 我相信，Base on corvus-skk 的 code 的話，
>> 基本上也會偷用到 MS 的code，
>> 可能還是自己重寫比較好，也比較乾淨
>>
>
> 我先重寫這部分，先有個可以動的 code 再看看要怎麼弄

我也想幫忙這部份，要不要來分工一下？
一人做一部份比較快?
我現在正在動 DllMain 和 class factory 的部份

BTW，我有個構想，就是把 TSF 相關的 code
移到自己的 folder 內，不要讓 COM 汙染其他 code
Chewing 的東西不要寫死在 tsf 的 code 裡面，
這樣以後 TSF 的 module 還可以被其他輸入法 reuse
例如 gcin...等等

[ChangZhuo Chen]

On Sunday, September 1, 2013 9:45:50 PM UTC+8, PCMan wrote:

我也想幫忙這部份，要不要來分工一下？
一人做一部份比較快?
我現在正在動 DllMain 和 class factory 的部份

BTW，我有個構想，就是把 TSF 相關的 code
移到自己的 folder 內，不要讓 COM 汙染其他 code
Chewing 的東西不要寫死在 tsf 的 code 裡面，
這樣以後 TSF 的 module 還可以被其他輸入法 reuse
例如 gcin...等等

ok，那我先研究一下 libchewing 接 C++ 和 UTF-16 的部分

code 都放在 [1]，剛剛把你加進來了，有進度就直接 checkin

[1] https://github.com/chewing/windows-TSF-chewing

[PCMan]

Thanks!
不過問題又來了，在 windows 8 內
metro app 內是不能用傳統 Windows API 做 UI 的，只能用 XAML
除此之外還有一狗票的 Win API 只有 desktop mode 可呼叫
不是只有 IPC 不行，而是有一大堆東西都不能用
連 non-GUI 的 code 都有很多不能在 metro 用
舉例，光 critical section 在 app mode 就不完全支援...這我剛才發現
而且還有很多的 windows API 都只有 desktop mode 可用...orz

要支援TSF就已經是重寫了，
要再支援 metro 基本上就是重寫再重寫
MS 是覺得開發者吃飽太閒嗎...
照這樣看來...我們還是支援 desktop mode 就好了
支援 metro app 付出的成本太大了，幾乎是另一個程式
讓開發者綁手綁腳的模式，只會讓 app 越來越少
這種架構早晚會滅亡的，我不想花力氣去支援了

不過，只要我們可以把 TSF 支援獨立成一個 module
那就可以套用這個 module，然後分別寫
給 desktop mode 和 metro app 用的輸入法 (如果將來真的有人想寫)
不但如此，我們可以直接 base on MS 的 sample code
建立 libTSFSupport.dll，這個 TSF supporting lib 可維持 MS-LDL 授權 (non-free)
而我們真正的輸入法部份，只是動態連結到這個 non-free lib，
所以本身還是可以維持 LGPL，這樣就不用浪費力氣在學 COM 重寫那堆 code
直接重用他的 code，或許這也是一個方法

2013/9/1 ChangZhuo Chen <czc...@gmail.com>:

[PCMan]

報告一下目前的進度和計畫，我開了一個新 branch: split-tsf
我把 M$ 的 TSF code 獨立出來，預計之後要改成 dynamic linking
變成獨立的 dll，例如 TSFHelper.dll
建立下列 abstract classes
CImeEngine: 把 CTextService 的部分 implementation detail，redirect 到
CImeEngine，有點像 pimpl 的 pattern
CImeContext: 把原先直接呼叫 ChewingContext 的部分，改呼叫 CImeContext，包括 key
handler，讓 CImeContext 來進行事件處理
CImeUI: 把原先建立 UI，Candidate windows 等 code，redirect 到 CImeUI，由 Ime UI
class 來進行真正的 UI 操作，這樣未來可抽換 UI
以上部分，留在 TSF helper library 裡面，使用 MS-LPL 授權

跟新酷音相關部分，可以留在 ChewingService.dll 內，這部分維持 LGPL
實作
CImeEngine => ChewingImeEngine
CImeContext => ChewingImeContext
CImeUI => ChewingImeUI
然後只在這些 class 裡面呼叫 chewing API

這樣作有幾個優點：
1. 不用浪費時間學 Windows COM 和重新發明輪子，可直接重用 MS 範例碼，大幅度加速開發，TSF lib 為 MS-LPL
授權，我們的 cheiwng 部分可以維持 LGPL 授權，互相不影響
2. TSF lib 不會有 libchewing dependency
3. 可抽換的實作，例如可以幫 metro app 重寫不同的 UI 實作 (如果有可能支援的話)
4. TSF helper library 未來可給其他輸入法 reuse (例: gcin, openvanilla, ...)

如果一切順利，就只剩下 hash 的問題沒解決
多個 process 同時讀寫 hash.dat 會造成無法預期的結果
解決方式如下：
1. 用 sqlite 取代 hash.dat，速度會慢一點，但是使用者詞庫數量不多，頂多數千，用 sqlite 綽綽有餘，或可用其他
lightweight 的 key/value db 實作
2. 用 mutex，在 Windows 下，named Mutex 可以跨 process，所以可以用來同步各個 process，這比
file locking 方便。我們用 cross-process mutex 保護 hash.dat 的讀寫就不會相衝了。問題是，一個
process 更新了檔案，另一個 process 並不會更新已讀到記憶體的部分。如果每次都檢查檔案是否更新，然後
reload，那效率也不好，不如用 sqlite

不知道大家覺得如何？
Comments are needed!


2013/9/1 PCMan <pcma...@gmail.com>:

[PCMan]

今日沒有進度，亂改一通之後 code 爛掉了...
連編譯都不過，所以沒有東西可以 commit
但是最大的收穫是，大概了解 TSF 的基本運作方式了
真是複雜到不行，一言以蔽之： overly-engineered
在紙上畫了滿滿一張流程圖終於知道了
原本 M$ 給的 sample 有點太複雜了，呼叫來呼叫去，繞來繞去
以我們的 case，有些功能其實不需要
我後來想想，搞不好 from scratch 重寫是比較好的選擇
我打算暫停修改現有的 TSF-chewing，
這幾天想試試看，有沒有辦法 from scratch 生出乾淨的 TSF code
如果可以做到最好，如果不行，再回來乖乖改 TSF-chewing
若有任何新進度，再跟大家報告
Thanks!

[ChangZhuo Chen]

On Monday, September 2, 2013 10:34:17 PM UTC+8, PCMan wrote:

今日沒有進度，亂改一通之後 code 爛掉了...
連編譯都不過，所以沒有東西可以 commit
但是最大的收穫是，大概了解 TSF 的基本運作方式了
真是複雜到不行，一言以蔽之： overly-engineered
在紙上畫了滿滿一張流程圖終於知道了

流程圖可以照相放到網路上嗎？剛剛去看 TSF-chewing，發現看不太懂。

hash 的部份，我想先研究一下 sqlite 看好不好改，以及效果如何。

[PCMan]

ok 我明天來照，畫得有點亂字很醜
因為本來沒計劃要給人看的 XD
剛原本想用 LibreOffice 重製，不過太複雜很難畫
就明天照相寄給大家

會這麼複雜主要的原因之一，除了 COM 以外
就是 edit session
接收到鍵盤訊息，不能直接處理，要先
把參數暫存起來，然後跟 TSF manager
要求 edit session，manager 准許了，
才會呼叫 Edit session 物件的 DoEditSession method
然後再從 Edit session 物建 call back 回 text service 本身
再取出先前暫存的參數處理，繞了一大圈
不管是按鍵處理、start composition, end composition
全部都要走這個模式

至於插入文字在那邊搞 selection range，是因為
插入文字其實就是「取代目前選取的文字」
而且進階的文字操作允許同時有多個選取區 (word似乎可以)
所以才要檢查 selection 和 composition 有無重疊
如果重疊才取代選取文字

剩下的全都是因為 COM 才變噁心的


2013/9/2 ChangZhuo Chen <czc...@gmail.com>:

[康家豪]

問一下前輩，如果是TSF架構的話，是不是就是只會支援Vista以上的系統？

PCMan於 2013年8月31日星期六UTC+8下午10時06分02秒寫道：

[Jui-Wen Hsu]

根據MSDN資料似乎XP以上都support.

http://msdn.microsoft.com/en-us/library/ms971336.aspx

--

您已訂閱「Google 網上論壇」的「Chewing IM Development」群組，因此我們特別傳送這封郵件通知您。
如要取消訂閱這個群組並停止接收來自這個群組的郵件，請傳送電子郵件到 chewing-deve...@googlegroups.com。
如要在此群組張貼留言，請傳送電子郵件至 chewin...@googlegroups.com。
請前往以下網址造訪這個群組：http://groups.google.com/group/chewing-devel。
如需更多選項，請前往：https://groups.google.com/groups/opt_out。

--
仁寶電腦工業股份有限公司  韌體部
許瑞文  (Lenny Hsu)
Email: lenn...@compal.com
phone: 0933243104
msn: rocf...@msn.com

[PCMan]

基本上會支援到 windows xp
畢竟我自己還在用 XD
但是 xp 上預設進階文字服務可能是關閉的
可能要手動開啟，否則非TSF aware程式會不能用

2013/9/12 康家豪 <otto...@gmail.com>: