[Linux] Some hotkeys don't work when non-English keyboard layout is selected

[geoku]

The title pretty much says it all.

Hotkeys that are mapped in Aegisub's settings are not accepted when keyboard input language is switched to non-English (specifically, Russian). When I switch to English, they work. It's extremely inconvenient to switch input language each time before using any hotkeys (even Ctrl+C / Ctrl+V don't work).

As a possible solution I tried to map alternative hotkeys with Russian input language active, but the program doesn't seem to accept any non-English letters as hotkeys.

This is not an issue on Windows, where mapped hotkeys work regardless of current input language.

[wangqr]

Which input method and which input framework (fcitx or ibus) are you using?

[geoku]

I'm quite new to Linux and not sure how to look up what framework is being used. Unfortunately, Google didn't help. Any advice?

[geoku]

So... no help at all?

I'm using a standard KDE Plasma installation on latest Arch. Input languages (English and Russian) are simply set up through KDE System Settings application. They work as intended everywhere in the system. No other application has trouble accepting hotkeys when input is switched to non-English (specifically, Russian). Only Aegisub has this problem.

I did not install ibus or fcitx, and from what I can tell, there's no sign of either being present on my system. I tested this by trying to install ibus and fcitx packages. My package manager didn't report either of them as being already present and prompted to download and install them, which I cancelled. So, neither ibus, nor fcitx are on my system.

[TheOneric]

Works for me with ibus and without it (presumably bare X11 input). But I didn't test with specifically Russian input. There is not enough information to tell what is going wrong for you. You could try to build and run wxWidget's Key Event Sample and look for any unexpected key codes/names. Or if this doesn' show something, maybe it's a Scintilla/wxSCT thing, in which case, try disabling syntax highlighting in the options or the corresponding wxWidgets sample.

[geoku]

There is not enough information to tell what is going wrong for you

Try this.

Enter something in text input area and press Ctrl+A. With English keyboard layout active it should highlight all the entered text, just as expected. Now try the same with Russian keyboard layout active. Now Ctrl+A won't do anything, it won't highlight the text. Admittedly, some keyboard shortcuts do work even with the Russian layout selected. But some do not, Ctrl+A is one of them.

I myself tested this on Arch with KDE and Gnome, also on Fedora with Gnome. Same behavior. I also asked a friend to install Aegisub on Kubuntu (old 3.2.2 version from repository) just to test this. He reported the same behavior. So it's a bug that survived through the years and is still present in this fork.

[karimstm]

I'm having the same issue on Ubuntu, hotkeys stop working with Arabic

[TheOneric]

@karimstm Can you give info on your input method (bare X11, bare Wayland, ibus, fcitx) and try if the wxWidget Sample for Keypresses works for you? If you're using one of the bare ones, can you try again with ibus or fcitx?

The samples should be packaged in recent'ish Debian-derived distros as wx3.0-examples. Install wx3.0-examples, libwxgtk3.0-gtk3-dev and build-essential. Then inside a terminal, go to some directory of your choice and run:

cp -r /usr/share/doc/wx3.0-examples/examples/ wx_samples
cd wx_samples/samples/keyboard/
make -j 2
./keyboard

to build and start the sample. When the sample application started and its windows is focused, press the combos that don't work in Aegisub and please report what keypresses are being logged.

[geoku]

The last question wasn't directed at me, but I'll still say that the issue is present in every major distro (Ubuntu, Kubuntu, Fedora, Arch) and is not specific to this fork, but happens in the old Aegisub version from repository as well. I don't really get the question about the input method. I'm not a Linux pro, I don't even have any idea how to check what my system uses. I just use the distros as they are, without changing anything related to that.

Testing it is literally a matter of seconds, just add Russian input language in your system, type something in Aegisub's main text input area, then press Ctrl+A. It won't do anything. Then switch to English and press Ctrl+A again, it will select all text as intended.

[TheOneric]

I don't even have any idea how to check what [input manager] my system uses

Check if any packages with ibus or fcitx are installed and the running processes. If ibus is installed and actively used, then

ps aux | grep -i ibus | grep -v grep

should show an ibus-daemon process to be running.

[geoku]

I am not on Linux anymore. I wanted to switch to Linux and was trying it out at the time when I opened this issue, and the reason I didn't switch to it is exactly this issue. Aegisub is unusable for me on Linux, and it's a program I use daily a lot.

[geoku]

So I just installed a fresh Ubuntu virtual machine to provide the info you requested.

user@VM:~$ ps aux | grep -i ibus | grep -v grep
user        1291  0.0  0.3 471412 12496 ?        Sl   08:03   0:00 ibus-daemon --panel disable
user        1677  0.0  0.3 324052 12148 ?        Sl   08:04   0:00 ibus-daemon --panel disable -r --xim
user        1778  0.0  0.1 172020  7236 ?        Sl   08:04   0:00 /usr/libexec/ibus-memconf
user        1782  0.0  0.1 172020  7200 ?        Sl   08:04   0:00 /usr/libexec/ibus-memconf
user        1783  0.3  0.7 355236 28684 ?        Sl   08:04   0:01 /usr/libexec/ibus-extension-gtk3
user        1796  0.0  0.6 202044 24860 ?        Sl   08:04   0:00 /usr/libexec/ibus-x11 --kill-daemon
user        1801  0.0  0.1 245796  7308 ?        Sl   08:04   0:00 /usr/libexec/ibus-portal
user        1816  0.0  0.1 172012  7320 ?        Sl   08:04   0:00 /usr/libexec/ibus-engine-simple

That shows that ibus is running.

Then I built the wxWidget Sample for Keypresses using the commands you provided.

Here's its output for Ctrl+A when English input language is active (works in Aegisub):

   Hook         CONTROL   308   C---    0 (U+0000)    65507    0x00000025  (  -27,  -86)
KeyDown         CONTROL   308   C---    0 (U+0000)    65507    0x00000025  (  -27,  -86)
   Hook             'A'    65   C---   65 (U+0041)       97    0x00000026  (  -27,  -86)
KeyDown             'A'    65   C---   65 (U+0041)       97    0x00000026  (  -27,  -86)
   Char          Ctrl-A     1   C---    1 (U+0001)       97    0x00000026  (  -27,  -86)
Test accelerator "Ctrl-A" used.
  KeyUp             'A'    65   C---   65 (U+0041)       97    0x00000026  (  -27,  -86)
  KeyUp         CONTROL   308   ----    0 (U+0000)    65507    0x00000025  (  -27,  -86)

Here's its output for Ctrl+A when Russian input language is active (doesn't work in Aegisub):

   Hook         CONTROL   308   C---    0 (U+0000)    65507    0x00000025  (   56,  315)
KeyDown         CONTROL   308   C---    0 (U+0000)    65507    0x00000025  (   56,  315)
   Hook             'ф'     0   C--- 1092 (U+0444)     1734    0x00000026  (   56,  315)
KeyDown             'ф'     0   C--- 1092 (U+0444)     1734    0x00000026  (   56,  315)
Test accelerator "Ctrl-A" used.
  KeyUp             'ф'     0   C--- 1092 (U+0444)     1734    0x00000026  (   56,  315)
  KeyUp         CONTROL   308   ----    0 (U+0000)    65507    0x00000025  (   56,  315)

As I've already mentioned in previous comments, Ctrl+A is one of the hotkeys that don't work in Aegisub with Russian input language active, but do work when English input language is active.

But then there are hotkeys that work with both languages. One example is Ctrl+V, which seems to work both with Russian and English input languages.

So, just for reference, here's Ctrl+V when English input language is active (works in Aegisub):

   Hook         CONTROL   308   C---    0 (U+0000)    65507    0x00000025  (  -27,  -86)
KeyDown         CONTROL   308   C---    0 (U+0000)    65507    0x00000025  (  -27,  -86)
   Hook             'V'    86   C---   86 (U+0056)      118    0x00000037  (  -27,  -86)
KeyDown             'V'    86   C---   86 (U+0056)      118    0x00000037  (  -27,  -86)
   Char          Ctrl-V    22   C---   22 (U+0016)      118    0x00000037  (  -27,  -86)
  KeyUp             'V'    86   C---   86 (U+0056)      118    0x00000037  (  -27,  -86)
  KeyUp         CONTROL   308   ----    0 (U+0000)    65507    0x00000025  (  -27,  -86)

And here's Ctrl+V when Russian input language is active (also works in Aegisub):

   Hook         CONTROL   308   C---    0 (U+0000)    65507    0x00000025  (  -27,  -86)
KeyDown         CONTROL   308   C---    0 (U+0000)    65507    0x00000025  (  -27,  -86)
   Hook             'м'     0   C--- 1084 (U+043c)     1741    0x00000037  (  -27,  -86)
KeyDown             'м'     0   C--- 1084 (U+043c)     1741    0x00000037  (  -27,  -86)
  KeyUp             'м'     0   C--- 1084 (U+043c)     1741    0x00000037  (  -27,  -86)
  KeyUp         CONTROL   308   ----    0 (U+0000)    65507    0x00000025  (  -27,  -86)

Hope this can help to fix the issue.

[TheOneric]

Thanks. So, unlike claimed in the first post, Ctrl+V(М) and Ctrl+C(С) (and Ctrl+X(Ч)) do work in the subtitle edit box (with ibus) — only Ctrl+A(Ф) from the combos mentioned does not work with ibus' default Russian keyboard layout. I can reproduce this regardless of whether the styled Scintilla-based editing box is used otr the unstyled one. Ctrl+A(Ф) also doesn't work in the subtitle list (but that can be simply remapped to match the keys available in the keyboard-layout, so not necessarily a bug, nope it can't, another bug).

However, in other input fields like the Style- and Actorname above the main edit box, Ctrl+Ф does select everything. It seems like somehow some, and only some, of the keycombos are prevented from being processed by the underlying GTK-textbox with Russian and allegedly Arabian keymapping, which is definitely a bug. Probably, caused by the scanning for Aegisub-specific hotkeys, but unfortunately it isn't obvious to me what specific part of the code is to blame.

If an Aegisub-hotkey is created for Ctrl+Ф this action gets executed as intended (the hotkey menu doesn't render the Ф character, but it works regardless). Nope, it get's mapped to Ctrl alone and I just didn't notice.

This does not happen with my default keyboard-mapping, which is non-English but latin-based and compared to a US-layout adds and swaps a few letters, including letters used in the GTK-provided text-manipulation keycombos.

[geoku]

So, unlike claimed in the first post, Ctrl+V(М) and Ctrl+C(С) (and Ctrl+X(Ч)) do work in the subtitle edit box (with ibus) — only Ctrl+A(Ф) from the combos mentioned does not work with ibus' default Russian keyboard layout.

Actually, Ctrl+V(М) and Ctrl+C(С) stop working for me randomly with the Russian input. It means they are working initially after starting Aegisub, but stop working at random point when working with the program. Restarting Aegisub makes them work again for some time. I can't find a sure way to reproduce this, it's not obvious to me which action may possibly trigger them to stop working, so I'm calling it "random" for the time being.

I just used Ctrl+V as the example of a "working" keycombo in my previous post, because it was working at the moment of testing. To be frank, I simply forgot the specifics of the issue I described in my first post, as some months have passed since then.

If an Aegisub-hotkey is created for Ctrl+Ф this action gets executed as intended (the hotkey menu doesn't render the Ф character, but it works regardless).

This doesn't work exactly right for me. After setting Ctrl+Ф as a hotkey for subtitle/select/all (as you mentioned, Ф is not rendered), it actually makes Ctrl+(Any Letter Key) select all the subtitles in the grid. So I guess Ф isn't just "not rendered", it's simply ignored, and somehow Aegisub thinks Ctrl+(Any Letter Key) is the hotkey I set up.

EDIT: More specifically, it's Ctrl+(Any Letter Key With Russian Input Active). When I switch to English, it stops processing Ctrl+(Any Letter Key) as a hotkey for selecting all the subtitles.

EDIT2: Just wanted to clarify once again that all of this is not an issue on Windows. Ctrl+A(Ф) and every other key combo is accepted correctly regardless of the active input language. Also, when I press Ctrl+Ф during shortcut creation on the Windows build, it correctly creates a shortcut for Ctrl+A, not Ctrl+ (blank space).

[TheOneric]

Actually, Ctrl+V(М) and Ctrl+C(С) stop working for me randomly with the Russian input.

That would be even more weird then.

After setting Ctrl+Ф as a hotkey […] it actually makes Ctrl+(Any Letter Key) select

Ohh, you are right I just didn't notice because that was the last bit I tested. So remapping also doesn't work, another bug.

when I press Ctrl+Ф during shortcut creation on the Windows build, it correctly creates a shortcut for Ctrl+A

That does not seem correct either. It should show Ctrl+Ф as that's the key you are pressing. Not the cyrillic А or the latin A. (Unless you are using a more complex IME on Windows, which sends the raw signals from another, eg US-layout but transliterates them to cyrillic letters, like eg mozc does for Japanese.)

[geoku]

It should show Ctrl+Ф as that's the key you are pressing. Not the cyrillic А or the latin A.

Why is that? It's not the way it works in any software. It should indeed accept and display Ctrl+A (Latin A, to be specific) regardless of the active input language/layout. It's the expected behavior and the way hotkeys are handled in literally all software in non-Latin locales across all the operating systems: they (hotkeys) are always in Latin regardless of the user input language/layout or the language program is displayed in. Hotkeys are always referenced and displayed in Latin in Russia, and I think this is true for every non-Latin language. It would be confusing otherwise (as an example, Latin A and Cyrillic А are on totally different keys, so we avoid confusion by always defaulting to Latin: when software or any text mentions Ctrl+A, we know it's always Latin A). When I press the hotkey combo to select all the text in the input field, I have the Latin A in mind, not the Cyrillic Ф (which happens to share the same key), and certainly not the Cyrillic A (which is on a totally different key). Nobody in Russia would want to specifically map Ctrl+Ф (Cyrillic) instead of Ctrl+A (Latin) as a hotkey. We expect to press Ctrl+A (Latin) and have it do its thing both with English and Russian input languages active, because we have to switch between input languages incredibly often. It would be insanely uncomfortable to have the hotkey work only in certain input language.

tl;dr Hotkeys are always referenced in Latin. When mapping hotkeys, it's expected that software will record and later accept them as if they were typed with the Latin layout active, even if another layout is actually active. Aegisub on Windows works totally correct in this regard. It's the way every other piece of software works, and it's the only convenient way.

My response is probably very redundant, sorry about that, but I'm not a native English speaker and I tried my best to explain my thoughts well.

[TheOneric]

[Mangling keynames to match what key it would be in a US-layout is] the expected behavior and the way hotkeys are handled in literally all software in non-Latin locales across all the operating systems

That is literally incorrect. Native GTK3-programs like MATE's hotkey-manager do show and listen for Ctrl+Ф and keeps previous hotkeys as how they were orignally typed. Testing Mumble as a QT5-program it shows this as Ctrl+Cyrillic_ef and also adjust previously set hotkeys to the new layout (meaning it stored the raw key-ids, don't know if that is a difference in QT/GTK-behaviour or a choice of the individual programs).

If you're using iBus' default Russian layout, this is the same as telling your OS that you are using an actual Russian keyboard, so naturally for users to have any clue what buttons will trigger the action without having to memorise some random foreign layout or get into ambiguity with similarly looking but distinct secondary labels, the labels shown for the hotkeys need to match what is actually supposed to be shown as the primary label on the physical keys on your keyboard, which is a Ф. QT5 and GTK3 evidently do use the primary labels as identifiers.

[geoku]

That is literally incorrect.

I agree, the part in my comment about "all operating systems" is probably incorrect. I don't have too much experience with Linux. But it IS the way it works and have always worked on Windows in any software, and no one expects a different behavior. Having software specifically map Cyrillic characters for hotkeys would be insanely inconvenient. I'll repeat myself, we need the shortcut to work in any input language, regardless of what language was active at the moment of setting up the hotkey.

I have Krita installed in my Ubuntu VM. I just entered keyboard shortcuts configuration, made sure I'm switched to Russian input language, clicked the hotkey setting for "Open File" and typed Ctrl+Ф. And of course, it correctly mapped Ctrl+A (Latin). And it works both with English and Russian input languages active. Pressing both Ctrl+Ф and Ctrl+A (same key, different input languages) brings up the "Open File" window. This is what I'd want. Believe me as a life-long Russian layout user, this is how hotkeys are handled and expected to work in our language.

And then there's GIMP. GIMP behaves just like you said. I mapped Ctrl+Ф for "Open File" as well. It indeed displays Ctrl+Ф, it accepts Ctrl+Ф only, and it won't work when the same key combo is pressed with the English layout active (which would be Ctrl+A (Latin)). Works only with Russian input active. You're saying that this is the correct behavior, but it's a nightmare user experience for any Russian user. Having to switch input languages before pressing a hotkey (which won't work otherwise) is hilariously stupid, mercilessly breaks the workflow and would drive people mad.

Thankfully, if I map Ctrl+A (Latin) in GIMP's settings, such hotkey combo also works when Russian input is active and Ctrl+Ф is pressed. But not the other way around. Why? Because Linux. But it doesn't bother me as long as Latin shortcuts work in Russian input language. I'd wish Aegisub on Linux could at least handle it the same way.

GIMP on Windows actually also displays Ctrl+Ф when mapping the hotkey (quite unusual behavior on Windows, maybe it's because of GTK), but at least, unlike on Linux, such "Cyrillic" hotkey will also work when English input language is active and Ctrl+A (Latin) is pressed. This is also acceptable.

As for Aegisub, I insist that it works correctly on Windows in regards to keyboard shortcuts. The way it handles it there is completely satisfactory and on par with how all the software does it. And no, I'm not using any "complex IME's", just barebones Windows (Windows 7, 10, 11 - it works the same across them all).

the labels shown for the hotkeys need to match what is actually supposed to be shown on the physical keys on your keyboard, which is a Ф.

This is not true. There's no "need" for this. You're probably not very familiar with Russian keyboards (just look up a picture of one) and the way computers are used here. Every letter key has two physical labels: one for English layout and one for Russian. I can assume it's the same with every non-Latin language. I know for a fact that it is the same for Japanese (BTW, don't you think Hiragana shortcuts would be hilarious? Imagine someone saying something like "Press Ctrl+さ to select all text"). Russian users are familiar with Latin layout (because it's impossible to use the PC without it) and always reference hotkeys in Latin layout, never in Russian. Literally nobody in Russia would say or write: "You have to press Ctrl+Ф to select all text", everyone will say "Ctrl+A", and they will mean the Latin "A", and it will be understood by everyone by default without the need to specify that the Latin "A" is meant.

Just because some developer (who probably has no idea how non-Latin users work with stuff) decided that you need to "help" Russians by displaying Cyrillic characters for hotkeys (and, what's worse, make said Cyrillic hotkeys work only with Russian input language) doesn't mean it's the correct and convenient way. It makes things literally unusable, and I'm not exaggerating.