On Fri Apr 7 12:47:27 2023 +0000, Jacek Caban wrote:
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).
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.