關於RIME的跨平臺圖形化配置工具
Ma Xiaojun
小狼毫具有一定的圖形配置能力，可以選擇啓用的方案，也可以選擇配色方案。
我希望實現一個跨平臺的配置工具，但是現在有以下的問題：
1、該配置工具是否依賴librime？
如果不依賴，那配置工具就基本上是手動修改的自動化。
如果依賴，那將來rime_api.h是否會增加相應的API？還是像小狼毫那樣說用rime/expl/*.h也所謂？
2、有沒有人可以提供一些UI上的hint？
主要是我自己絕對不算是RIME的設置專家，只是覺得這麼好的輸入平臺因爲配置較難將一些用家拒之門外很是可惜。
我自己的設想：一個是類似ibus-setup的rime-setup，選方案，選配色，選熱鍵等（歡迎補充！）
另一個是針對每一個方案的rime-schema-setup，具體定製些啥還沒想好，肯定有候選詞數目……
Wish
推广这个想法，则所有的方案级设定和全局设定都可以用这种方式来解决
说的可能不太清楚，换种说法，我们在方案里直接定义所有的可选项，然后配置模块运行时自动读取这些可选项并且构建出UI。可选项的种类不会太多（text,
checkbox, combobox, color, font就差不多了），所以UI部分应该不会太难。
而这样好处是，做配置模块的UI就不用去考虑各个方案到底是怎么弄的了。做方案也不用考虑配置UI怎么设计了，只要把可以配置的部分声明起来就可以了。
刚刚开始研究rime，对架构还不太了解，请继续讨论！
2012/8/13 Ma Xiaojun <damag...@gmail.com>:
> --
>
>
>
佛振
wishstudio於 2012年8月13日星期一UTC+8下午6時38分37秒寫道：
自己心中理想的方案应当是由输入法方案在定义中指定哪些选项是可以修改的（比如形码可能需要设置自动上屏，而拼音则不需要）。所以需要在yaml里定义一组用来指定设置选项的语法
推广这个想法，则所有的方案级设定和全局设定都可以用这种方式来解决说的可能不太清楚，换种说法，我们在方案里直接定义所有的可选项，然后配置模块运行时自动读取这些可选项并且构建出UI。可选项的种类不会太多（text,
checkbox, combobox, color, font就差不多了），所以UI部分应该不会太难。而这样好处是，做配置模块的UI就不用去考虑各个方案到底是怎么弄的了。做方案也不用考虑配置UI怎么设计了，只要把可以配置的部分声明起来就可以了。
刚刚开始研究rime，对架构还不太了解，请继续讨论！
2012/8/13 Ma Xiaojun <damag...@gmail.com>:
> 安�好之後��RIME需要修改文本文件�配置，�用家��可能是一�不小的surprise。
> 小狼毫具有一定的�形配置能力，可以���用的方案，也可以��配色方案。
> 我希望��一�跨平�的配置工具，但是�在有以下的��：
>
> 1、�配置工具是否依�librime？
> 如果不依�，那配置工具就基本上是手�修改的自�化。
> 如果依�，那��rime_api.h是否�增加相�的API？�是像小狼毫那��用rime/expl/*.h也所�？
>
> 2、有�有人可以提供一些UI上的hint？
> 主要是我自己��不算是RIME的�置�家，只是�得��好的�入平�因�配置���一些用家拒之�外很是可惜。
> 我自己的�想：一�是�似ibus-setup的rime-setup，�方案，�配色，���等（�迎�充！）
> 另一�是��每一�方案的rime-schema-setup，具�定�些啥��想好，肯定有候���目……
>
> --
>
>
>
Ma Xiaojun
> 想法很好，我也是這樣想的。不過有個關鍵問題：跨平臺的設置程序用啥寫？
依賴librime的話得用C++語言，Qt、wxWidgets都可以，雖然都和std::*|boost::*有點阻抗不匹配，但是小狼毫用的MFC其實一樣阻抗不匹配。
不依賴的話，我個人傾向用Python語言，PyYaml在Ubuntu 12.04中都有打包（yaml-cpp還要自己編譯）
佛振
後來急於實現【小狼毫】的基本設置，就用WTL寫了一個，原生技術就是好，依賴少，體積、速度都一流。但這樣開發效率真是低啊。
【鼠鬚管】也急需設置程序，本想學着用Cocoa，可我猶豫了……
內嵌Web服務器，Windows上有個小小的問題，會彈出防火牆的警告。可能削弱用戶對產品（或技術）的信任感。
還有一個思路，是把瀏覽器控件嵌入程序內，綁定一些JS對象。相對於調用瀏覽器，內嵌的WebUI體驗較好。不過開發成本更高，而且要增加一些依賴的軟件包。
佛振於 2012年8月13日星期一UTC+8下午11時26分57秒寫道：
想法很好，我也是這樣想的。不過有個關鍵問題：跨平臺的設置程序用啥寫？
Ma Xiaojun
> 之前一個思路是，內嵌一個輕量級的Web服務器（mongoose），直接打開瀏覽器展現HTML介面。
好想法！
> 後來急於實現【小狼毫】的基本設置，就用WTL寫了一個，原生技術就是好，依賴少，體積、速度都一流。但這樣開發效率真是低啊。
> 【鼠鬚管】也急需設置程序，本想學着用Cocoa，可我猶豫了……
表示Chromium自己封裝了一套UI庫……
> 內嵌Web服務器，Windows上有個小小的問題，會彈出防火牆的警告。可能削弱用戶對產品（或技術）的信任感。
如果只是listen本地主機也會嗎？參見：
http://stackoverflow.com/questions/3375435/avoid-windows-firewall-popup-with-sockets-on-localhost
> 還有一個思路，是把瀏覽器控件嵌入程序內，綁定一些JS對象。相對於調用瀏覽器，內嵌的WebUI體驗較好。不過開發成本更高，而且要增加一些依賴的軟件包。
這個我也想到過，像Hotot就是這種思路？
只不過我們有沒有這麼強的平面設計能力？沒有的話還是普通青年用用一般的桌面控件算了，畢竟現在是完全沒有UI而不是UI太丑了。
佛振
因爲擔心，要將設置程序做得足夠通用，也會很費功夫，幾乎要實現一套小小的介面語言了。而且萬一哪個方案有點奇特的設計，就要擴展這個設置系統。
一些設置功能的最佳形式很難確定，比如模糊音設置，對於方言輸入方案來說，很可能設計成先選擇地域，或出幾道選擇題考察一些字的同音關係，以推斷該使用者的方言需要打開那些模糊音選項。這些顯然需要一種能夠快速迭代的開發方式，HTML+JS非常適合這項任務。
佛振於 2012年8月13日星期一UTC+8下午11時41分08秒寫道：
Ma Xiaojun
至於方案的高級定製，可能你作爲主要開發者會更清楚需求，我反而無從下手……
佛振
而且這個「介面」輸入法只需打包一些HTML、JS文件等，從自私的角度也可算作輕量級啦！
雖然Web服務器不是很大，但是也不宜直接集成到輸入法程序裏。我今天正好在考慮這件事呢，一個做法是把設置模塊做成一個插件模樣的東西，用到時加載進來。
或者，把設置程序做成獨立於輸入法進程（如WeaselDeployer目前的做法），考慮二者怎樣通信的事情。
很顯然前者的好處是可以獲取輸入法的實時狀態，後者則只能從文件系統讀取YAML，若是用戶詞典管理（加詞、刪詞、導入導出），後者會比較麻煩，因爲輸入法會以獨佔方式打開用戶詞典文件；
後者的好處是設置程序比較純粹，流程簡單，對YAML做完手腳，通知Rime重新加載就完了。
Ma Xiaojun於 2012年8月13日星期一UTC+8下午11時50分39秒寫道：
Ma Xiaojun
> 用樸素的HTML，力求清晰、實用，稍微用CSS修飾一下就好。畢竟要照顧還在用IE6的同學……就不趕HTML5的時髦了。
而且樸素的HTML我不覺得能比本地控件好……
> 而且這個「介面」輸入法只需打包一些HTML、JS文件等，從自私的角度也可算作輕量級啦！
用瀏覽器的技術我覺得必然是相對慢的……空間佔用倒是不一定多……不過現在空間不是問題吧……
> 雖然Web服務器不是很大，但是也不宜直接集成到輸入法程序裏。我今天正好在考慮這件事呢，一個做法是把設置模塊做成一個插件模樣的東西，用到時加載進來。
> 或者，把設置程序做成獨立於輸入法進程（如WeaselDeployer目前的做法），考慮二者怎樣通信的事情。
> 很顯然前者的好處是可以獲取輸入法的實時狀態，後者則只能從文件系統讀取YAML，若是用戶詞典管理（加詞、刪詞、導入導出），後者會比較麻煩，因爲輸入法會以獨佔方式打開用戶詞典文件；
> 後者的好處是設置程序比較純粹，流程簡單，對YAML做完手腳，通知Rime重新加載就完了。
兩種方式也不是完全互斥，但是基本的功能用後者就行了，有個設置程序不比自己改yaml強多了……