#osxchat blog

2005/07/21

OpenVanilla 發展所遇到的挑戰,及一些可能的解決方向

作者: lukhnos

有好一陣子沒在 #osxchat blog 上寫東西了。先前寫 blog ,泰半是撰寫關於 OpenVanilla 的版本發佈、少許是一些 Mac 的使用心得。算起來這些都屬於「務實」的 blog 。今天我要講的是比較「務虛」的東西:關於 OpenVanilla 的未來發展。不是技術面的發展,是社會面的。

簡單地說,OpenVanilla 目前在使用及發展上,有以下幾個層面的挑戰:

  • 使用上的疑難,包括 OpenVanilla 的安裝、解除安裝、移難排除等等
  • 自訂輸入法(Generic輸入法)模組的使用
  • 如何修改或更新現有的輸入法(資料表或演算法)
  • 在 OS X 上某些軟體的不相容問題
  • 如何撰寫新的輸入法
  • 文件的撰寫、更新與維護
  • 如何在其他平台上使用 OpenVanilla 框架(亦即如何移植 OpenVanilla)
上述的列表有層次上的分別。前兩項是使用上的,後面五項則是開發上的。這幾個挑戰有相扣的環節。

OpenVanilla 會發展到今日的規模,說實在話,有那麼點意外(大概幾個成員間也這麼覺得)。我蠻希望強調 OpenVanilla 應該簡稱 OV 而儘量避免用「開放香草輸入法」這樣的譯名,因為 OV 是為了這幾個目的而設計的:

  • 將 OS X 的輸入法處理模組(text service component)分離,讓每個輸入法開發者不需要重頭研究 OS X 的 Text Service Manager
  • 讓開發輸入法的人能專心於輸入法的演算法及邏輯程序
  • 透過動態載入的方式,讓輸入法框架能同時載入多種輸入法,並即時切換
而自從 OV 0.7.0rc3 正式加入了「文字輸出處理模組」(output filter)這一層架構後,上述的設計目的又增加了「提供一套加掛文字輸出模組的方式,讓輸入法打出的文字,能夠透過不同的轉換模組(filters)進行變換」這一項。

然而,正因為 OV 的設計目的和設計方針是如此,以致於 OV 面臨相當獨特的挑戰。例如說,OV 並不是「一套」輸入法,而是「很多套輸入法的組合」,或者說 OV 其實是「一套可以載入各種符合 OV 規格的模組的框架」──因此與其說「OS X 內建的倉頡不好用,裝開放香草輸入法吧」,不如說「裝 OpenVanilla,用它裡面附的倉頡輸入法吧」。我們有「OV 倉頡」、「OV 大易」、「OV 酷音」、「OV 傳統注音」甚至是「OV 漁村」等輸入法,但是「OV」只是一套框架,一個殼子,一套載具而已。

因此,要回答 OV 使用上的疑難問題,恐怕還是得先問「用哪一套 OV 的輸入法」。好比說,OV 倉頡在使用上和 OV 大易所會碰到的問題,就未必相同。如果 OV 倉頡使用者遇到問題,能有同樣使用 OV 倉頡的人來回答,其實是最適合的。

我想,這就是目前 OV 團隊遇到的一個瓶頸:OV 的每一個開發者所熟悉的輸入法數量都有限。例如我一直只熟悉傳統注音輸入法,因此對於 OV 酷音,我只負責模組的編譯(build)、佈建(deployment)及包裝。又好比最早完成的通用輸入法模組(這個模組藉由資料表,生出了倉頡、大易、漁村等輸入法),後來也是因為有熟悉倉頡的 b6s 出手,才更臻完善。再譬如說 OV 的行列,最早是由我從通用輸入法模組撰寫,經過 ijliao、xeonchen、gontera 等朋友的耐心協助測試,開始稍具雛型,但是一直要等到 vgod 加入 OV 開發,以他身為行列使用者的親身體驗,才終於讓 OV 有了完全符合行列規格的輸入法模組。OV 的 POJ (台語白話字)模組也是因為有 pcchen 的「壓力測試」才能有今日的表現。

也就是說:OV 提供了框架,然而要解決某一輸入法的問題,最終還是要由熟悉該輸入法的人來解決,最為妥當。

就目前這個階段,我們能做的,就是盡可能提供完整的文件說明──儘管 OV 的文件,也已經長大成為了龐大的計劃。OV 的文件一直是由 zonble 和 mjhsieh 帶頭編輯的。0.7.0 版的說明文件(尚未正式發表),竟然已經是 54 個 A4 頁面的大傢伙,絕對可以印一本中等厚度的使用手冊。

然而,總一定會有手冊不能完善解決的,或是新產生的問題。這種時候,如果有使用者社群,情況就會改觀不少。

除了使用者社群,另一個我心裡面期望的,是能有 OV 的開發社群。這裡的「開發社群」,我心裡預想的倒不只是「撰寫、維護或修改輸入法模組/輸入法資料」的人群──儘管連這一點的規模都還不大──反倒是,如何讓更多人能從原始碼層次,直接編譯、佈建、安裝,甚至包裝 OV 。我的想法是,如果能有更多人瞭解 OV 是怎麼從原始碼編譯、安裝的,相信對於任何想要修改、建立新輸入法的人來說,都會有幫助。

換個方式說,目前要瞭解這些東西,必須憑藉少量的文件,或者直接與 OV 開發團隊聯繫上(主要還是靠 IRC)。然而不可否認,即使在網路上,人際距離還是存在的。更多人瞭解 OV 的組建,我的想法是,應該能縮短這樣的距離。好比說,如果能有更多使用簡體中文的朋友,能對 OV 的組成有更多瞭解,那麼例如在修改五筆輸入法資料,或是在建立新 OV 輸入法模組時,就能省去很多力氣。

在這一點上,有幾個困難點要克服,因為 OpenVanilla 在原始碼層次上,主要運用了以下三個工具:

  • gcc 及 gcc 相關工具(make)
  • Xcode
  • svn 及版本管理工具
其中,gcc 或許對許多有 UNIX 經驗的朋友不是難事,但是對許多未曾在終端機工作過的朋友,會形成一定的挑戰(我們倒是成功地讓一位頻道上的朋友,因為想要取得 OV 最新版本的關係,而開始用命令列編譯建立安裝 OV !)。而 Xcode 則往往是對任何人都很新鮮的。至於 svn ,在國外的自由軟體/開放源碼軟體界,已經漸漸開始風行起來,但是版本管理的觀念和工具一定程度上還是有進入障礙的。

要推廣 OV 從原始層次碼來安裝、維護、修改或演進,就一定會碰到上述這三個層次:OV 使用很多 UNIX 工具、OV 需要使用 Apple 的 Xcode (至少在 OV 的 OS X 版本是如此)、OV 是一個使用 svn 當版本管理工具的 open source project。反過來說,如果 OV 開發社群的成長過程,同時也是這三種工具的推廣過程,應該也會是很有意思的事。

至於,OV 在其他平台上的發展,似乎也必須仰賴有更多人能擔當 OV 的「種子推廣者」,協助更多人取得 OV 源碼、在不同平台上建立 OV 、解答 OV 使用上(尤其是安裝,及個別輸入法的使用、維護、修改)的問題,才有可能繼續進行下去。

簡言之,面對我一開始所列的 OV 諸多挑戰,用 gugod 的說法,叫 SIGMOREHACKERNEEDED (這個詞是仿 UNIX signal 的組合字:需要更多人來 hack)。而「形成各別輸入法的使用者社群」和「(藉由 OV 源碼層次組建方法的流傳)形成 OV 的開發者社群」這兩點,則是我目前認為更具體化的方向。

標籤: , ,

0 篇留言:

張貼留言

? 回前頁