Created attachment 165324 [details] Screenshot of Kodi (windowed mode), trying to make it full-screen mode by pressing the "/" key while the layout is in Romanian and Kate showing the character for both English and Romanian layouts. SUMMARY Shortcut not working in Kodi when the keyboard layout is other than English STEPS TO REPRODUCE 1. Add a non-English keyboard layout 2. Install and open Kodi 3. While having the English keyboard layout press the "/" twice 4. Change the Keyboard layout to the non-English layout (I tested with Romanian and Italian) OBSERVED RESULT With the English layout, pressing the "/" key, Kodi is successfully switching between its windowed mode and full-screen mode. With Romanian and Italian and I assume with other non-English languages too and possibly with ever language that changes the key from "/" character to another one, Kodi is not successfully switching anymore between its windowed mode and full-screen mode. EXPECTED RESULT Kodi is successfully switching between its windowed mode and full-screen mode, like with the English layout Inputting Romanian, Italian and whatever other non-English characters into Kodi to still be possible so we can still search for movie names, plots, taglines, actors, add-ons that have strings in Romanian, Italian, and whatever other non-English language we might use. So, in Romanian for example, if you decide to fix it by silently converting in the background the "â" character with "/" character so Kodi receives the same character as in English, you must make sure this does not break our ability to actually type inside Kodi the "âÂăĂîÎșȘțȚ" in text input fields, like the ones to search for items or to edit the names of items. And of course the same for the other non-English languages SOFTWARE/OS VERSIONS Linux/KDE Plasma: KDE Plasma Version: 5.92.90 KDE Frameworks Version: 5.249.0 Qt Version: 6.6.1 ADDITIONAL INFORMATION KDE Neon fully updated, showing Plasma 6.0 RC1 Using the Wayland session Kernel Version: 6.5.0-15-generic (64-bit) CPU: Intel Core i5-8250U GPU: Integrated UHD 620 ADDITIONAL INFORMATION It seems similar to this fixed bug here: https://bugs.kde.org/show_bug.cgi?id=309193 Andrey's comment #76 says it should it was fixed in Qt for local shortcuts and in Kwin (Wayland) from global ones: https://bugs.kde.org/show_bug.cgi?id=309193#c76 But to me it seems that it was not or this case, with Kodi has something different. Please see the attached screenshot where I've put in Kate on the first line the character that the key I'm pressing does for English on the first row and on the second the character that it does for Romanian, if it's any help.
Global shortcuts work fine on my machine when using ukrainian and greek keyboard layouts. App specific shortcuts are handled by the apps. Please report this issue to kodi developers, maybe kodi needs a fix of its own.
Going with the idea that shortcuts might not work in more programs that have them on characters that might be replaced in other languages layout, I tried to find a few more especially for the ones that I now are replaced like the:',",\,/,[,],+,- and I think I found a few more: CTRL plus + / - to increase / decrease text size doesn't work in Kate and Firefox, while keyboard is in Italian, because +=^ and -=? / to do a quick find doesn't work in Firefox, while keyboard is in Italian, because /=- ' to do a quick find (links only) doesn't work in Firefox, while keyboard is in Italian or Romanian, because '=à (Italian) and '=ț (Romanian) I bet there are more programs that have this problem. I hope something can be done that doesn't require conversion as in pretty much all of them, no matter it's Kodi, Kate or firefox or others, we need to be able to write non-English characters too.
(In reply to Vlad Zahorodnii from comment #1) > Global shortcuts work fine on my machine when using ukrainian and greek > keyboard layouts. App specific shortcuts are handled by the apps. Please > report this issue to kodi developers, maybe kodi needs a fix of its own. I tested again, including the languages you specified, please have a look: Urkrainian \=ґ - Κodi windowed / full-screen toggle fails! /=. - Firefox quick find fails +=+ - Firefox and Kate text increase works -=_ - Firefox and Kate text decrease works '=є - Firefox quick find (links only) fails! Greek: \=\ - Κodi windowed / full-screen toggle works /=/ - Firefox quick find works +=+ - Firefox and Kate text increase works -=_ - Firefox and Kate text decrease works '=' - Firefox quick find (links only) works Italian: \=ù - Κodi windowed / full-screen toggle fails! /=- - Firefox quick find fails! +=^ - Firefox and Kate text increase fails! -=? - Firefox and Kate text decrease fails! '=à - Firefox quick find (links only) fails! Romanian: \=â - Κodi windowed / full-screen toggle works /=/ - Firefox quick find works +=+ - Firefox and Kate text increase works -=_ - Firefox and Kate text decrease works '=ț - Firefox quick find (links only) fails! BTW, can someone please remove the 4 language layous maximum or increase it to 7 or so, on the layout switcher? For this test I had to keep removing other languages so I can test new ones. Ι even removed English to make it faster. It looks to me that the problem is more widespread than just Kodi as I initially thought. And I don't think I and anyone else can keep up with writing so many bug reports for Kate, Kodi, Firefox and I assume there could be tens or hundreds other programs that have this problem. Even when I write the bug report for one program, let's say Kodi, what should I say to them: Hei, when you receive they key "ґ" in Ukrainian or "ù" in Italian or "â" in Romanian treat it as you would treat "\" received in English? Same for Kate and Firefox and I assume all Mozilla's products. I bet LibreOffice could have hundreds of shortcuts and for sure some of them are with these special characters which are replaced in other languages. I'm not sure if it's feasible for them to do all that. I wonder how this problem was solved on Windows as as I used Windows 7 for more than 10 years, Kodi too for about the same period and also had Romanian as an alternative language layout and I don't remember ever to run into this problem. Maybe it was sending behind the scenes the English characters all the time, but I then wonder how it knew to not do that when I acutally need to insert some text in Romanian. Anyway, do you still think Kodi developers can solve this problem on their side? What about the similar problems in Kate and Firefox?
Other problems, with Italian and Romanian layouts: Firefox (go back and forward) fails with these shortcuts, that work with the English layout: CTRL + [ CTRL + ] Actually for Italian is worse here as only CTRL + ] works and that does other thing, which is zoom in and I don't know how to zoom out, except for Ctrl + 0, which thankfully works. I have yet to test in Chromium-based browsers, when I will have the time. But thinking about how Windows does this successfully, I tried to search a bit about this problem and how it can be solved and I think I found a good article, for web developers, but anyway, maybe it's useful for any developer who wants to solve this problem here too: https://tkainrad.dev/posts/why-keyboard-shortcuts-dont-work-on-non-us-keyboard-layouts-and-how-to-fix-it/ And if you folow that link inside that neat little web tool, that points here: https://w3c.github.io/uievents/tools/key-event-viewer.html I see that, if I try to test the first problematic key,\ for Kodi, then: charCode keyCode which code key Input field 0 220 220 Backslash \ '\' - English (US) 0 220 220 Backslash ù 'ù' - Italian 0 220 220 Backslash â 'â' - Romanian 0 220 220 Backslash ґ 'ґ' - Ukrainian 0 220 220 Backslash \ '\' - Greek We see that only the "key" and "Input field" change when the keyboard layout language is changed. Can't Kwin or whoever is dealing with getting keyboard input and passing it to programs just pass the non-changing things, like the "keyCode", "which", or "code"? I mean, since the physical keyboard is actually the same for English and every other language, then the other language layouts are just some post-processing / faking on the actually key that was pressed so we can type characters in other languages, shouldn't for shortcuts just be sent the key codes of the actually keys that were pressed on the keyboard? Can't a program in Linux receive keyboard inputs on 2 channels, for example: Channel 1: Original, non-post-processed / non-faked key codes to be used for shortcuts. Channel 2: Post-processed / faked / translated keys, characters to be inserted as they were received, such as text, emojis, whatever ? I don't think anyone or many bother to create programs that accept shortcuts in multiple languages with other than English characters since many of us have physical US-based layout keyboard, but I might be wrong as I've seen that at least Germany and Italy have a lot of actual physical layouts with their languages layouts. Though I never heard of Firefox or any other program have non-English shortcuts.
Sorry for reopening this but I added additional comments for the tests that I did later and I'm not sure they were read. Plus I don't know if this can be solved downstream as compared to my initial though of this affecting only Kodi, it seems the more I look for programs not using only latin characters shortcuts, the more I find them not working and I don't think I will be able to create alone so many bug reports. And I want to add the fact that I did two more tests: Besides Kate and Firefox having a problem with zoom in / out when pressing CTRL + + / -, when the keyboard layout is Italian, Thorium & Ungoogled-Chromium are affected too and neither of the two shortcuts work, in either of them, I assume Chrome is affected too. Using this website, that I found in the article from my previous comment: https://keycombiner.com/collecting/collections/public/search/?description=&keys=%5C&mac_keys=&submit=Search I tried to see if there are more programs that have in their shortcuts this character "\", like Kodi, which seems to be used for other letters a lot in non-English layouts and to my surprise, Nano, which I use a lot, as I hate both Vim and Emacs, seem to use it with this combination: Alt + \, description "to top of buffer" and from my test I see that is used to go to the top, beginning of the document being edited. With English layout seems to work as described without problem. But with Italian, Romanian, Ukrainian layouts, it fails! Luckily, this program it so well made, that it's the first one that it even shows what is the problem, instead of silently ignore it like the others. For all these 3 languages that I tested and the shortcut doesn't work it shows the following message: [ Unknown sequence ] (with red background) If anyone wants to do more tests, I think using the keycombiner website to search for programs that have shortcuts including this characters: /,\,[,],',",-,= it's a good way to start as these seems to be the most switched characters when they layout is changed to non-English languages.
And more bad news... I have tested how it's the situation in Gnome (version 43.9, Wayland on Debian 12 live mode) And Cinnamon (version 5.8.4, on LMDE 6 live mode) With just the \ shortcut for Kodi and CTRL + + / - and / ' shortcuts for Firefox for Italian and Romanian keyboard layouts. And unfortunately it's exactly the same as in Plasma, they fail the same way and work only the English layout. Because of this comment: https://bugs.kde.org/show_bug.cgi?id=462274#c2 I thought that there is a small chance for this to be Wayland-only, at least on Plasma, but it's not, the problem is there too for al the tested programs and layouts. I'm starting to be inclined to think this is a Linux problem, not a DE or program problem, which others might confirm, having similar problems: https://github.com/celluloid-player/celluloid/issues/576 Sublime text users having this kind of problem too: https://github.com/sublimehq/sublime_text/issues/392#issuecomment-79022157 https://github.com/sublimehq/sublime_text/issues/392#issuecomment-131031043 BTW, in my comment #3, which I cannot edit, this line: \=â - Κodi windowed / full-screen toggle works Should be \=â - Κodi windowed / full-screen toggle fails! Like for Italian where \=ù and Ukrainian where \=ґ And I have finally found a place where \ doesn't work for the English layout too: That is of course when it waits from some text input like if you go: cogwheel (settings) icon -> Add-ons -> Search Now even if you press the \ key, it will actually be inserted into that text field instead of toggling the window size as it normal does for English layout. I got the idea to test this when I saw that someone was saying in a bug report here that there's a difference if the program has a text input field focused or not: https://bugs.kde.org/show_bug.cgi?id=462274#c0 So at least for Kodi, from what I can understand until now, there are 3 cases possible: 1. An active input field present: It will skip any shortcut processing and insert that, be it characters \ (English + Greek), ù (Italian), â (Romanian), ґ (Ukrainian) 2. No active input field present: It will try to process that as a shortcut, which WORKS if \ (English + Greek) 3. No active input field present: It will try to process that as a shortcut, which DOESN'T work and if ù (Italian), â (Romanian), ґ (Ukrainian) are given as they are not recognized as any possible shortcut So I'm wondering, can any code in Kwin detect if a program has an active or focused text input field so it knows to send whatever character in whatever language or if it doesn't, then send only the ones in English (as int that case only shortcuts can be sent ans most of them must be in english)? Can Kwin send characters on 2 different channels, one for whatever texts and one for shortcuts only or only one channel but with some metadata attached so the program knows what is the purpose of those characters (text input or shortcut)?, Can these two comments be of any help of solving this problem?: https://bugs.kde.org/show_bug.cgi?id=434228#c2 https://bugs.kde.org/show_bug.cgi?id=434228#c3
I'm not sure why this bug report has been reopened. kwin sends clients both native key scan code and the current keymap, it's up to the client how they are interpreted. For global shortcuts, the clients should use native scan codes rather than use keysyms (i.e. after mapping the native scan code using the keymap). This has to be reported to the app developers, and yeah I can confirm that many apps handle shortcuts with non-english keyboard layouts poorly, but we cannot do anything about it on the compositor side, we already send all the required information to assist the apps.
This is not an app problem, but KDE as a whole. Set CTRL-/ (the key right to left hand Shift). It will work with English, Russian, but not Estonian layout. I believe this fixing this bug should fix all other issues as well: https://bugs.kde.org/show_bug.cgi?id=453661