I'm using two keyboard layouts (English and Czech) and a custom global shortcut (Meta+K) for switching. When I'm in the chat window, the Czech layout is activated (for example) and I press Meta+K, Plasma shows me an "OSD image" of keyboard being switched to English but that in fact doesn't happen. When I use the icon in the system tray instead of the keyboard shortcut, everything works as expected. Reproducible: Always Steps to Reproduce: 1. Configure two keyboard layouts. 2. Open the chat window. 3. Press a keyboard shortcut for layout switching (Ctrl+Alt+K by default, IIRC). Actual Results: The layout isn't switched. Expected Results: The layout should be switched.
Thanks for the report Is this happening only in ktp-text-ui? Or also in other applications?
Only there. It works properly in all other applications that I use.
Ok, it's probably due to the layout-per-tab handling the text-ui uses. I'll have a look.
Are you able to test patches btw?
Actually, what would be easier, please install bustle, run bustle, open some chat, switch the keyboard layout, stop bustle, save the log and attach it here. You can also email it directly if you're concerned about your data (it may contain your account and the chat contact).
Ok, after inspecting the bustle log and the code, I think I see the problem. In app/chat-window.cpp, the restoreKeyboardLayout(..) is called on various occasions, this in turn calls the setLayout on the keyboard switching interface. I guess it's called with the old layout from somewhere. I'll investigate more properly later tonight. Oh and btw, for testing patches, you'd need to recompile only ktp-text-ui, should be really simple :)
Ok I understand now what's going on. It's...unexpected. So. If you use "save layout per tab", the layout is set everytime you switch to the window (make it an active window). Now when you press the key combo to change layout, the OSD popups up and that takes the focus away from ktp-text-ui, even if for a split of a second. After that, the text-ui is switched back to, ie. made an active window. At this point, text-ui is setting the "old" layout back (because the updated layout didn't make it to it yet). And that makes it look like it's blocking the change.
Some updates. I made a patch yesterday [1] fixing this problem. I've added Martin G to the review which prompted him to look for the root cause of the bug (described in previous comment) and it will likely get fixed elsewhere, but for the time being the exact cause of the WindowDeactivate/WindowActivate events is still unknown. [1] - https://git.reviewboard.kde.org/r/126287/
*** Bug 333742 has been marked as a duplicate of this bug. ***
It works properly now in 15.12.1.