もずはっく日記(2010年9月)

MacでのIMEまわりのバグ修正はOSの設計の問題との戦い
初回投稿日時: 2010年09月18日13時12分47秒
カテゴリ: 雑談
SNS: Tweet (list)

本当にどうなってんだというぐらいに、MacのAPIやイベントモデルは最悪きわまりないですね。Cocoaのキー入力、テキスト入力を書いたことある人なら誰しもが賛同してくれるんではないかと思いますが。

キー入力の方はkeyDownとperformKeyEquivalentという二つのイベント的なメソッドが用意されていて、一筋縄ではハンドリングできません。幸いにもJoshが_wantsKeyDownForEventという隠しメソッドの存在を発見し、これによりkeyDownだけで概ねほとんどのキーイベントをハンドリングできるようになり、かなりのバグが消えましたが。普通に考えればperformKeyEquivalentが何故存在しているのかさっぱり分かりません。また、keyDownの戻り値がvoidなのも変です。普通、イベントを処理した後にそのイベントを消費するのかどうするのか選択できるものですから。

さらに奇妙なのがinterpretKeyEventsです。keyDownでこのメソッドを呼ぶと、IMEにキーイベントが渡されます。ですが、なんとこれも戻り値がvoidで、アプリケーションからはそのキーイベントがIMEに消費されたのかどうか、一筋縄では判断できません。この問題の解決はFx4以降での課題となっています(ATOKの確定アンドゥがGeckoで機能しないのはこの問題)。

interpretKeyEventsに戻り値がないという致命的欠陥を除けば、IMEに処理が渡る前にアプリケーションがキーイベントに介入できるという点は、それができないWindowsや、事実上できないGTK2に比べると良い面もあります。ただ、IMEの処理とアプリケーションの処理がバッティングした場合、普通はIMEが勝つべきなので(アプリケーションが勝つと、IMEのその機能を利用できませんが、逆の場合はIMEをオフにすれば利用できる)、結局あまり使いどころがないメリットです。

また、他のOSからは信じられない設計のひとつに、IMEとキーボードレイアウトが同列に扱われている、という独特の発想があります。他のOSでは、キーボードレイアウトの選択と、その選択したキーボードレイアウトでのIMEのオン、オフという二つの概念があります。ところがMacではキーボードレイアウトとIMEの各入力モード(たとえばひらがな、カタカナ等)のスイッチがダイレクトに行えてしまいます。また、現在のキーボードレイアウトが他のOSで言うIMEオンの状態の場合、IMEオフにあたるキーボードレイアウトは発見できるのですが、その逆に関しては最後に選択されていたIMEオンにあたるキーボードレイアウトを探すことはできません(記憶しておくしかない)。APIの不備、とも考えることができますが、どちらにしろ、そのIMEで対になる状態のキーボードレイアウトを非表示にされているともうどうしようもありません(たとえばATOKをインストールして、英数入力にはことえりのものを残し、ATOKはひらがなとカタカナを残し、他を全て非表示にしてしまった場合)。

さらに、キーボードレイアウトとIMEとを同列に扱うということはIMEそれぞれがキーボードレイアウトも管理しなくてはいけないことを意味します。もしDvorakのレイアウトでIMEを利用したい、と思っても原理的に難しいのです。たとえば、Dvorakを選択し、次にことえりのひらがなを選択するとキーボードレイアウトはJIS配列に戻ります。Macにおいてはこれが正しい流儀と言えます。ことえりのやり方とは対照的にATOKは直前に利用されたASCII互換のキーボードレイアウトをそのまま利用してあたかも引き継いでいるかのように振る舞いますが、スペイン語のキーボードレイアウトなんかでテストしてみるとあっさり破綻します。当たり前ですが。

これ以外にもIMEのAPIがフォーカスがあるコンテキストでしか動作しないとか、正気を疑う設計が多いです。Appleのこの辺の設計はアプリケーションのために設計したというよりも、自社アプリにとって必要最低限のものだけ用意しておけば良いという発想なのではないかと勘ぐってしまいます。