-
-
Notifications
You must be signed in to change notification settings - Fork 171
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Language layout does not switch automatically #3857
Comments
What sort of session are you using? "seamless" or "desktop"? |
I am using "seamless" session (launching one application - I've tried terminal and browser at different times). You are absolutely right, I also came to the conclusion that the client is to blame. If you manually switch the layout in the client (from the tray menu), then it switches, but when you return to auto mode, nothing changes and it remains the one that was last selected manually. I tried to run the client on windows 7 x64, but this did not bring any changes. Then I tried several older versions of the client, also to no avail. Now I'm stuck and don't know where to go next. |
Perhaps we're not receiving the keyboard layout switching events, or not processing those properly. |
launched as you indicated. When switching the layout, the lines run, but their meaning is not clear to me). I attach the log from the beginning of the connection to the end, the moment in the log when I press the layout switching keys 2023-05-18 16:17:20,971
|
What are these layout switching keys and how is the system configured? I would have expected to see a WM_INPUTLANGCHANGE event, which should have printed a message: xpra/xpra/platform/win32/win32_events.py Line 64 in 89b4838
Sadly, it is unreliable If the system call is fast enough, perhaps we could call GetKeyboardLayout for every keystroke. |
Keys for switching - shift + alt.
I tried to change the keyboard shortcuts, tried to press in different ways... the event, at least related to languages, did not appear in the debug log. |
we don't seem to be getting the WM_INPUTLANGCHANGE message reliably, so we have to use polling. and we have to use a different thread (we use the main thread via GLib) because otherwise we get stale values for the keyboard layout
@nvaleryRR please try the latest windows beta build at r33476 or later. |
Checked. Works great! |
OS client - windows 10 22H2
Client Xpra-Python3-x86_64_Setup_4.4.4-r1.exe
OS Server - ubuntu mate 22.04
Server Xpra - from the stable repository xpra 4.4.4
From the Windows client, the session is started (with the launch of xterm) and attached to it.
When switching the input language from English to Russian (using hot keys or using the mouse on the language bar), the keyboard stops typing. When switching back to English, the keyboard prints normally. In this case, it all depends on which input language was selected during the launch of the session from the client to Windows. In the input language that was selected at the start of the session, character printing works fine, but if you switch the input language to another, printing stops. To be able to print in a language other than the one selected at the start of the session, you have to go to the settings of the running session and transfer the layout from the auto state to the desired language, then printing becomes possible, exactly until you switch the language again. It's terribly inconvenient to constantly climb into the menu to switch input languages. I can't figure out if this is a bug or if I'm doing something wrong. How to make the input language switch automatically when hotkeys are pressed (shift + alt or shift + control).
The text was updated successfully, but these errors were encountered: