[PATCH v2 4/4] user32: Move (Un)LoadKeyboardLayoutW from winex11.drv to user32.
Rémi Bernon
rbernon at codeweavers.com
Fri Apr 23 13:46:52 CDT 2021
On 4/23/21 8:25 PM, Dmitry Timoshkov wrote:
> Rémi Bernon <rbernon at codeweavers.com> wrote:
>
>> Signed-off-by: Rémi Bernon <rbernon at codeweavers.com>
>> ---
>> dlls/user32/driver.c | 26 ---------------
>> dlls/user32/input.c | 53 ++++++++++++++++++++++++++-----
>> dlls/user32/user_private.h | 2 --
>> dlls/winex11.drv/keyboard.c | 21 ------------
>> dlls/winex11.drv/winex11.drv.spec | 2 --
>> 5 files changed, 45 insertions(+), 59 deletions(-)
>
> This patch is going in the wrong direction IMO, it won't allow implementing
> proper support for keyboard layouts and WM_INPUTLANGCHANGE using XKB keyboard
> groups. I sent a patch that implements ActivateKeyboardLayout() using XKB
> extension, and top of it WM_INPUTLANGCHANGE could be added:
> https://www.winehq.org/pipermail/wine-devel/2020-April/164161.html
> Unfortunately it was ignored.
>
> How are you planning to implement support for keyboard layouts without
> support on the driver side?
>
I'm not sure to be honest, and as I indicated in my comment it's very
possible indeed that this is not the right thing to do. Also, I don't
yet see how this last patch is doing anything wrt the patch you sent.
This is only removing LoadKeyboardLayout which doesn't do anything,
currently or in your patch.
My general feeling is that although it may be nice for the integration,
it's going to be hard to implement keyboard layouts by bridging it
directly with the host. Also I'm not sure having Windows applications
messing with the keyboard layout is a great user improvement. (In the
same way Windows apps messing with the display resolution isn't, in my
opinion).
I also don't know how the graphics drivers are going to be treated with
the 32on64 transition, but my understanding is that the less we do on
the unix side, the better we are.
So overall, I'm tempted to think that if we want that kind of feature,
implementing everything on the Win32 side would be better ultimately
(but a lot more work, true). We would be able to properly implement
thread-local or process-wide layout changes without being limited by
what the host can provide.
--
Rémi Bernon <rbernon at codeweavers.com>
More information about the wine-devel
mailing list