wxWidgets/キーイベントの処理順 - wxStyledTextCtrlでの日本語入力 @ ウィキ

キーイベントの処理順

Macで入力した文字を確定できない問題と絡む話。Input Method対応にする際に解決しなければならない。

キーイベントを処理するかもしれないもの:

• アプリケーション (EVT_KEY_DOWN)
• Input Method
• Accelerator

この3者のうちのどれが優先されるべきか?

現状

キーを押したときのイベントがどの順番で処理されるか

wxMSW

WM_KEYDOWN

1. Input Method
2. Accelerator
3. アプリケーション

Input Methodでイベントが消費された場合、wParamがVK_PROCESSKEYになっている。かなり早い段階でIMEに処理されるようだ。IMEに先んじるには…フックか?

wxOSX/Cocoa

NSResponder の keyDown: メソッド

1. Accelerator
2. アプリケーション

Input Methodに渡っているのか不明。一応src/osx/cocoa/window.mmのwxWidgetCocoaImpl::DoHandleKeyEventでinterpretKeyEvents:を呼んでいるようなのだが…

wxOSX/Carbon

kEventClassKeyboard/kEventRawKeyDown

1. Accelerator
2. アプリケーション
3. Input Method
   • CarbonEvents.hのコメントによるとkEventRawKeyDownが処理されなければTSMが処理するらしい

wxGTK

"key_press_event"

1. アプリケーション
2. Input Method (gtk_im_context_filter_keypress)
3. Accelerator

src/gtk/window.cppのgtk_window_key_press_callbackを参照。

理想

1. Input Method
2. アプリケーションやAccelerator

Input Methodの処理がアプリケーションの後になると、入力した文字を確定する前の操作が制限される恐れがある。この結果、例えばwxRichTextCtrlでは、確定はできるが←→キーでの文節の移動や、エスケープキーでの入力取り消しができない。wxStyledTextCtrlでは確定すらできない。

実装するには

• GTK+はgtk_im_context_filter_keypressを呼ぶ位置を変えればいい。
• CocoaのOSX 10.6で追加されたAPI(-[NSTextInputContext handleEvent:])ではInput Methodがイベントを処理したかどうか教えてくれるが、
• OSX 10.0からある-[NSResponder interpretKeyEvents:]ではInput Methodが処理したかどうか分からない。
• CarbonもInput Methodが処理したかどうか分からない…いや、kEventRawKeyDownイベントを直接application targetに送ってやれば…でも面倒だな…

…と思ったけど、Input Methodに処理させるとwxでいうところのEVT_CHAR(kEventClassTextInput/kEventTextInputUnicodeForKeyEvent,inputText:,"commit")が発生してしまうなぁ。EVT_KEY_DOWNよりも前にEVT_CHARが発生するのはまずいか。普段は

1. アプリケーションやAccelerator
2. Input Method

としておいて、確定前の編集中だけ

1. Input Method
2. アプリケーションやAccelerator

に切り替えるのがいいのか? それとも、前に書いたパッチみたいにEVT_CHARを起こす直前にEVT_KEY_DOWNを起こすか?