On Fri Apr 7 12:47:27 2023 +0000, Rémi Bernon wrote:
For a better understanding, this is how I plan the internal interface to be: https://gitlab.winehq.org/rbernon/wine/-/blob/wip/ime/include/wine/ime.h The host IME would call back into the IME by sending the messages to the right IME UI window. They need to be able to make changes to an HIMC from any thread, and this which will allow to delegate the operations to the owning thread. For some implementations, the PE IME needs to call into the driver unix side, for instance to pass keys to be processed. It could be done by keeping ImeProcessKey export and a driver specific unixlib interface, but this new imm32 unixlib let us factor this into imm32.dll, and also lets us target other host IME, like IBus, directly instead of going through the user drivers, using the same unixlib interface.
It's nice to see it all going in this direction. I have some thoughts on the interface to consider. In general, I think we could leverage win32u interface more to avoid some unixcalls and perhaps make the interface a bit lighter.
How about using pseudo-window messages for PE->Unix calls too with `NtUserMessageCall`, similar to how we do with `NtUserClipboardWindowProc`? We could have a dedicated message type for IME window and calls to those would be forwarded to a dedicated driver entry point. Drivers could then implement it themselves or ask win32u to handle it. I guess IBus code itself could be in win32u, avoiding the need for imm32.so and making backend choice internal to win32u.
I'm also not sure we need ime.h. Unix interface parts can be in gdi_driver.h, things like window messages could go to ntuser.h (similar to how we extend winternl.h).