輸入法廚房

作者: gugod

這次輸入法廚房的活動，主題便是 Leopard 裡新介紹的輸入法架構：InputMethodKit。整體看起來，與 OpenVanilla 所想要完成的事情很不相同。整個 InputMethodKit 裡頭分成三大部份：Server、Controller、CandidateWindow。而在 OpenVanilla 0.7 裡，大致是拆成 Loader、DisplayServer；而在 OSX 上，Loader 的部份還要拆成 TSMComponent、CocoaLoader 兩部份，TSMComponent 使 OV 可以成為 OSX Text Service Manager （TSM）的一個外掛，而由此外掛載入 CocoaLoader，將所有的輸入法模組載入進來。Leopard 上的 InputMethodKit 所達成的功能，一方面是全面取代原有的 Text Service Manager，另一方面則同時提供了 DisplayServer 顯示選字窗的功能。

在 InputMethodKit 的架構之下，與以往比起來，便是輸入法一口氣由 TSM 外掛，提升成為了應用程式。選字窗很自然地就成為了此應用程式的視窗，此應用程式與其他應用程式不同，它是完全的背景應用程式。所謂背景應用程式，在 OSX 上的說法，就是「執行時不會在 Dock 出現，也不會出現在 Recent Item 清單裡」的應用程式。只要一有切換輸入法的動作，作業系統便會自動執行輸入法的應用程式，但一但此輸入法應用程式執行了一次之後，除非該程式因故終止，否則不會再執行第二次。

這種做法，很明顯地對於記憶體用量會大有改進，因為，在作業系統運作期間，一個輸入法只會被載入一份。如果是以前採用外掛的方式，跑了幾支應用程式，記憶體中便會有數份輸入法。但難處便是，以往只要以函式呼叫便可寫的輸入法，現在要以行程間通訊扯上關係。為此，InputMethodKit 便直接利用了 Objective C 裡的分散式物件，來解決通訊的問題，所以對於寫輸入法的人來說，這是無需處理的細節。

用 InputMethodKit 來寫輸入法，可以直接使用 Xcode 開始寫一個 Cocoa Application，整份 InputMethodKit 都是 Objective C 的函式庫。程式設計師需要做的，大抵便是定義自已的 InputMethodServer 子類別，並定義其 inputText 方法，該方法是個整體的入口，收字元、顯示組字、選字窗、出字串。若要分得細一點，可以自行創建自已的 InputMethod Engine 類別，再於 inputText 方法中，將查表組字的部份完全交遞給 InputMethod Engine 去辨。這 InputMethod Engine 並不是 InputMethodKit 架構的一部份，只是為了讓程式邏輯更加分明，而分開來的另一個類別。與 OpenVanilla 比較來看， inputText 函式便是存在於 Loader 之中，而 InputMethod Engine，就是 OpenVanilla 的輸入法模組。

目前為止並沒有什麼太難的地方，寫完一整個以前的 BasicInputMethod，必要的 Objective C 程式碼不出一百行。可以說，InputMethodKit 將事情簡化的程度，大致上就跟 OpenVanilla 框架是差不多的。這兩天下來，頭痛之處是在弄懂 InputMethodServer 需要的 plist 內容。因為都是應用程式，必需要跟其他的應用程式有所區別，Leopard 的文字服務才可以將此應用程式視為一輸入法，將之載入，並放置於輸入法選單當中。最重要的，便是 CFBundleName 這個識別字的值，需要包括 "inputmethod" 這個字串。如 "org.openvanilla.inputmethod.phonetic"。並不會真的造成程式上的問題，但是對於本來不依此慣例取名的人來講，還得全面將自已的 CFBundleName 都改掉，果然還是有一些代價的。

此外，InputMethodKit，不，應該說 OSX；「輸入法」一詞，在 OSX 的定義，其實與台灣人一般的認知有一點差異。它們所指的「輸入法」，是在輸入法選單中出現的主要項目。如「繁體中文」、「Koetori」、「Hangul」。而其下的子項目，它們稱為「輸入法模式」。對於日文 Koetori 來說這比較沒有什麼問題，平假名與片假名被認為是日文輸入法的兩個模式，也還說得通。但是在兩種中文輸入法底下，以「模式」相稱，反而不對頭。倉頡與行列，並不算是中文輸入法的兩種模式。不過，這說起來只是名稱問題。最主要的重點還是在於，每個「輸入法」是一個應用程式。也就是說，整個繁體中文底下的所有輸入模式（倉頡、漢音、拼音...），其實都是寫在同一個應用程式當中。

這一點對於 OpenVanilla 的架構來講，也不會有很大的影響，反而應該是一個有利的地方。OpenVanilla 架構早就將輸入法獨立成為模組，所以要把輸入法模組調整成 InputMethodKit 可以接受的「輸入法模式」也就行了。

但實做上面，把輸入法模組換成輸入法模式，可能是最難的一點。因為，在 InputMethodKit 裡，所有的輸入法模組都是事先定義在 plist 當中，說起來竟算是個「應用程式設定值」的概念。要 OpenVanilla 來說，也就是要先做一份完整的輸入法模組列表，才能在輸入法選單中，將輸入法模式正確顯示出來。

但這跟 OpenVanilla 目前的做法是完全相反的。OpenVanilla 一直以來都是使用動態載入的方式。大家可以將輸入法模組裝到 /Library/OpenVanilla/ 目錄底下，然後 Loader 會自行偵測並載入。載入了之後，再動態去修改選單的內容。如果要事先將輸入法模組列表做完，那麼使用者就變成沒有選擇，必需要安裝所有的輸入法模組才行了。以 OpenVanilla 專案來說，也可以完全不要理會輸入法模式這個部份，只要一直保致一貫做法即可。比較合理的應用，也許是將 SpaceChewing 輸入法，以 InputMethodKit 重新寫一次，並把各種鍵盤排列做為不同的輸入模式。