Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

WM_IME_* support in win32 #508

Closed
kwonoj opened this issue May 9, 2018 · 2 comments
Closed

WM_IME_* support in win32 #508

kwonoj opened this issue May 9, 2018 · 2 comments
Labels
C - needs discussion Direction must be ironed out DS - windows S - enhancement Wouldn't this be the coolest?

Comments

@kwonoj
Copy link
Contributor

kwonoj commented May 9, 2018

(Probably other platform may need specific support as well, this issue only intend to track win32)

Win32 exposes number of IME-related message to let application handle, most notably
WM_IME_SETCONTEXT / WM_IME_STARTCOMPOSITION / WM_IME_COMPOSITION / WM_IME_ENDCOMPOSITION / WM_INPUTLANGCHANGE (and few others like WM_IME_CHAR).

These message requires specific processing and return value of LRESULT based on processing - i.e for WM_IME_SETCONTEXT,

  1. Application decides to create own IME wnd or not, calling ImmIsUIMessage. If it created one, clear ISC_SHOWUICOMPOSITIONWINDOW from lparam.
  2. if application called ImmIsUIMessage or DefWindowProc for own IME managing, return it's return valus as LRESULT, or just forward message to DefWindowProc and return it's value as LRESULT.
  3. Once application owns IME handling, other IME messages (i.e WM_IME_COMPOSITION) should not forward message to DefWindowProc, instead have to foward it to own IME window instead.

Couple of things I couldn't wrap my head around for those implementation are

  • How to event loop get LRESULT value from callback, if application processed it / determine if it wasn't processed by application callback
  • This requires application need to specifically manage ImmIsUIMessage (or DefWindowProc per preferences) when decided to manage IME handling, probably too low level exposure. Maybe there need to be some sort of manager to wraps up? (and those manager also stores context of application level IME status, manages forward message to DefWindowProc or not as well)
@kwonoj
Copy link
Contributor Author

kwonoj commented May 9, 2018

Somewhat related: servo/servo#18202 + servo/servo#20770

@kchibisov
Copy link
Member

The ime is now supported on windows.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
C - needs discussion Direction must be ironed out DS - windows S - enhancement Wouldn't this be the coolest?
Development

No branches or pull requests

6 participants