On Fri Apr 7 13:22:13 2023 +0000, Rémi Bernon wrote:
I have tried to use win32u for things that seemed to be obvious and generic, like for instance I'm using NtUserNotifyIMEStatus, and I keep the IME UI window in the win32u HIMC attributes, so that it's easily accessible from the unix side. Then, for some other calls like ImmProcessKey, I haven't found any obvious way this gets passed to the kernel side. Regarding user callbacks, I also considered integrating the IME UI communication interface directly within win32u, like you suggest, but the helper for the drivers is simple (https://gitlab.winehq.org/rbernon/wine/-/blob/wip/ime/dlls/winex11.drv/xim.c...) and it didn't seem to be worth adding Wine-specific mechanism. Using standard window messages, like for instance WM_SETTEXT, allows us to leverage the message behavior (to copy the string data for instance), with a message semantic specific to the default IME, which is known and used from the host IME integration code. Having a dedicated custom mechanism for the callbacks, even with a message-like interface, we'd just have to duplicate the message behavior in a new set of user callbacks. Generally speaking I'm also not sure that this default IME impl should really be so deeply integrated with win32u. In general, I think the user drivers are doing too many things at the same time. And while I understand that it is necessary for some things like X11 / XIM, in my opinion it often makes things hard to untangle. This interface is also specific to the default IME, and we want to keep in mind that we are (supposedly) supporting native IME too. Of course, we don't want to interact with them from the host IME side, and that could also be checked from imm32, but I think it then makes sense to treat the default IME as just another IME, and not something very integrated with win32u.
Re-reading the comments I think I might have been slightly confused, but fwiw the PE->Unix calls are mostly just about passing ImmProcessKey to the drivers (and really just winemac at the moment).
My current IME interface has more, but they are just there for convenience and integration with IBus in imm32.so, which shares the same "ime_funcs" set of callbacks.
The IME messages are rather the other way around, from Unix to PE, whenever the host IME replies with new IME result or candidate strings. This may come from a separate thread (and this is what I am actually trying to address, as I think we should have a dedicated keyboard input thread), and they need to be forwarded to the right thread to update the input contexts.
I'm currently using the IME UI window for that because it seems to be a clean and simple way to do it.