Our menus have accelerators for items - keys which, when pressed, trigger a menu item without having clicked it nor moved down with the keyboard to it. These are in the UI's language; I'm focusing here on the US English UI. Well, if I switch my keyboard layout from English to pretty much anything else -Arabic, Hebrew, Russian - the accelerators don't work. That is, the physical keys which would correspond to the English accelerators don't trigger the menu items they're supposed to. If, however, I enable the "Ignore system input language" option in Tools > Options > Languages & Locales > General - the accelerators _do_ work. Notes: * This is not a new issue, I'm just getting around to filing it right now, somehow. * Saw this on a couple of modules, so I believe it's a problem in all modules. Build info: Version: 24.2.4.2 (X86_64) / LibreOffice Community Build ID: 51a6219feb6075d9a4c46691dcfe0cd9c4fff3c2 CPU threads: 4; OS: Linux 6.6; UI render: default; VCL: gtk3 Locale: en-IL (en_IL); UI: en-US and also: Version: 24.8.0.0.beta1 (X86_64) / LibreOffice Community Build ID: 318462181c709ed29c01eb3239b4d600d7b82ecc CPU threads: 4; OS: Linux 6.6; UI render: default; VCL: gtk3 Locale: en-IL (en_IL); UI: en-US
The original problem of shortcuts not functioning with different keyboard layouts was considered in bug 41169. But shortcuts don't really get mentioned there.
(In reply to Eyal Rozenberg from comment #1) Please note, that bug 41169 was not about menu accelerators (the underlined characters in menu item names, that may be activated by pressing things like F10, then the underlined characters): bug 41169 was about shortcuts like Ctrl+B (Cmd+B in bug 41169 comment 2 from the OP there), which are configured in Customize->Keyboard. AFAICT you never mentioned what *exactly* fails for you; please provide that exact key sequence that fails for you.
(In reply to Mike Kaganski from comment #2) Fair enough. Reproduction instructions: 1. Create a new document in Writer, or Impress, or Calc 2. Set your keyboard layout to something sufficiently different than English, e.g. an Arabic, Hebrew or Russian layout. 3. Enter the File menu (e.g. using Alt + "English-F" - the keyboard key which, in English layout, would produce "F") 4. Press "English-t", i.e. the keyboard key which, in English layout, would produce "t" Expected results: We are targeting the "Expor&t..." item; it is triggered, and the Export file picker dialog pops up. Actual results: Nothing happens (or possibly, a character is typed).
Created attachment 195059 [details] A screencast on Windows (In reply to Eyal Rozenberg from comment #3) Aha, that's what I thought (and what is different from bug 41169). In the meanwhile, I recorded a screencast on my Windows box (the OS is definitely important). I used Alt+O->X->B for Format->Text->Bold (and also Ctrl+B); I didn't re-record, but I tried with Alt+F->T after reading your reply, and it indeed works correctly, just as with Alt+O->X->B. So my recording is how it is *intended* to work. Version: 24.2.4.2 (X86_64) / LibreOffice Community Build ID: 51a6219feb6075d9a4c46691dcfe0cd9c4fff3c2 CPU threads: 24; OS: Windows 10.0 Build 22631; UI render: Skia/Raster; VCL: win Locale: ru-RU (ru_RU); UI: en-US Calc: CL threaded
Ok, marking as a Linux issue for now.
Just as a data point. Testing LibreOffice under Ubuntu *under WSL* (which may change everything), I indeed see that the accelerators don't work, when I have Russian keyboard layout / system input language. Keyboard shortcuts don't work, either. But in this case, the "Ignore system input language" checkbox doesn't make a difference. As said, the WSL may be completely different, because it may completely change how the input is sent from Windows to the Linux subsystem. Version: 24.2.4.2 (X86_64) / LibreOffice Community Build ID: 420(Build:2) CPU threads: 24; OS: Linux 5.15; UI render: default; VCL: gtk3 Locale: en-US (C.UTF-8); UI: en-US Ubuntu package version: 4:24.2.4~rc2-0ubuntu0.22.04.1~lo1 Calc: threaded
(In reply to Eyal Rozenberg from comment #0) > If, however, I enable the "Ignore system input language" option in Tools > > Options > Languages & Locales > General - the accelerators _do_ work. > ... > CPU threads: 4; OS: Linux 6.6; UI render: default; VCL: gtk3 Note that this seems to create some way to actually detect the system input language on GTK, and so fix bug 108151 for that integration.
Something interesting has occurred... When filing this bug, I had two taskbar applets on, which should a language indicator: The Cinnamon Keyboard, uh, taskbar thingie; and something else which IIANM is ibus-related. And when I would switch keyboard layouts, only the first of these would reflect the switch. Well, if I terminate the latter, while keeping the former, I no longer see the buggy behavior. Note: Both before, and now, I was able to switch keyboard layouts and type text in each of those layouts. But now, somehow, LO is not "fixated" on the belief that I'm in English layout as far as menu accelerators are concerned. And - this fixation perhaps relates to the additional keyboard layout indicator.
(In reply to Eyal Rozenberg from comment #8) > When filing this bug, I had two taskbar applets on, which should a language > indicator: The Cinnamon Keyboard, uh, taskbar thingie; and something else > which IIANM is ibus-related. And when I would switch keyboard layouts, only > the first of these would reflect the switch. Can you please clarify exactly what the "ibus-related" indicator is and what package added it? Are you on Linux Mint?