[PATCH v2 4/4] user32: Move (Un)LoadKeyboardLayoutW from winex11.drv to user32.

[Rémi Bernon]

On 4/23/21 8:54 PM, Dmitry Timoshkov wrote:
> Rémi Bernon <rbernon at codeweavers.com> wrote:
> 
>>> 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.
> 
> That patch doesn't implement LoadKeyboardLayout(), however it makes it
> possible.
> 
>> 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 have an application that on startup changes keyboard layout to Russian,
> so that an operator can readily start typing in the input fields. That's
> very helpful.
> 
> Also, it's not only about messing with layouts, it's about making applications
> detect available input locales and correctly handle input locale changes. For
> instance Winword highly depends on this.
> 

I'm not saying we shouldn't support switching input locales, but that 
/correctly/ implementing the Windows input locales probably requires to 
do it in Wine.

(To be clear, I'm replying here for the sake of the argument but I've 
got no plan to do anything about it. I was only factoring driver code, 
and this last patch could very well be ignored like I said).


1) Assuming each thread can have a different input locale, which is a 
legacy behavior according to MSDN, we could imagine the following scenario:

An application with a child window running in a separate thread from its 
parent. If the child window thread calls ActivateKeyboardLayout, the 
vkey and char events it'll receive should use the new layout, while the 
vkey and char events the parent receive should still use the default layout.

The way winex11 is currently structured (and I don't see this changing 
any time soon), the toplevel window would translate X11 events to vkeys 
messages according its locale, which would be wrong if the child window 
has input focus.


2) MSDN now mentions that ActivateKeyboardLayout / LoadKeyboardLayout do 
a system-wide change, as long as the calling application is foreground.

This makes things simpler in some sense, and that would solve the issue 
from 1), but then implementing it (somehow) and letting Wine change 
system-wide input locale is in my opinion risky. I would rather see Wine 
input locale management not leaking out.

There's several (a lot of?) ways to change input locale on Linux, I 
didn't even play with many of them but as far as I could see already 
they don't work together very well.

For instance, I can change input locale through setxkbmap (which Wine 
sees when detecting keyboard or xkb groups btw), or using GNOME language 
switcher (which Wine doesn't see). Both aren't synced at all, and I 
don't think adding Wine to the party would help.

FWIW I also tried your patch and it wasn't able to change anything as 
far as I could tell (I used setxkbmap fr,us to setup two groups and 
tried switching between them, but the fr translation was always active).


I don't know what the best solution here is, but I think maybe we should 
have some input locale support implemented inside Wine, eventually 
monitor host input locale changes to select the corresponding locale 
internally too.

This would also let Wine support input locales on systems without any 
native input locale support or ways to change it system-wide (if there 
are any and if we consider portability beyond X11 / macOS / Android).

Then I agree that being able to use the host input locales directly is 
also something that is nice to have, especially for user with customized 
layouts.
-- 
Rémi Bernon <rbernon at codeweavers.com>