Bug 466053 - Keyboard layout switch hotkeys work improperly and inconsistently with more than two layouts
Summary: Keyboard layout switch hotkeys work improperly and inconsistently with more t...
Status: RESOLVED DUPLICATE of bug 444569
Alias: None
Product: plasmashell
Classification: Plasma
Component: Keyboard Layout (show other bugs)
Version: 5.24.4
Platform: openSUSE Linux
: NOR normal
Target Milestone: 1.0
Assignee: Andrey
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2023-02-19 06:31 UTC by Michael Lashkevich
Modified: 2023-03-31 10:25 UTC (History)
1 user (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments
My settings (in Russian, unfortunately). (77.16 KB, image/png)
2023-02-19 06:31 UTC, Michael Lashkevich
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Michael Lashkevich 2023-02-19 06:31:13 UTC
Created attachment 156476 [details]
My settings (in Russian, unfortunately).

I have four layouts (English (default), Russian, Hebrew and Yiddish) with a layout loop of maximum 2 layouts. I assigned the keyboard combinations (hotkeys) for each layout (Meta+1, Meta+2, Meta+3, Meta+4 correspondingly). When I switch to Hebrew (Meta+3) or Yiddish (Meta+4) I cannot return to Russian with Meta+2. Instead, Meta+3 works as turning to Russian and Meta+4 works as turning to Hebrew from Yiddish. Meta+2 doesn't work at all. It seams that the keys are associated to the order of languages in a cycle rather that with the languages themselves. I tried to change hotkeys, but it helps nothing. In previous versions (in OpenSUSE up to 15.3) everything worked properly.

My ~/.config/kxkbrc looks like:

[$Version]
update_info=kxkb.upd:remove-empty-lists,kxkb.upd:add-back-resetoptions,kxkb_variants.upd:split-variants

[Layout]
DisplayNames=,,,
LayoutList=us,ru,il,yi
LayoutLoopCount=2
Model=asus_laptop
Options=grp:rctrl_toggle,lv3:ralt_switch_multikey
ResetOldOptions=true
ShowFlag=true
ShowLabel=false
ShowLayoutIndicator=true
ShowSingle=false
SwitchMode=Window
Use=true
VariantList=intl-unicode,ru_local,lyx,israeli

STEPS TO REPRODUCE
1. Set several (n) languages in the keyboard layouts configuration.
2. Set layout loop to m<n
3. Assign a hotkey to every language.
4. Try to switch to any language number k>m with the corresponding hotkey.
5. Try to switch to any language number l<=m with the corresponding hotkey.

OBSERVED RESULT
Nothing happens or the language is switched randomly.

EXPECTED RESULT
The language is switched to the language l.

SOFTWARE/OS VERSIONS
Linux/KDE Plasma: OpenSUSE 15.4
KDE Plasma Version: 5.24.4
KDE Frameworks Version: 5.90.0
Qt Version: 5.15.2

ADDITIONAL INFORMATION

I use slightly modified xkb rules and symbol settings to adjust my habits with the Russian keyboard and to use the Yiddish keyboard. It has never caused any problems.
Comment 1 Andrey 2023-02-19 15:50:27 UTC

*** This bug has been marked as a duplicate of bug 444569 ***
Comment 2 Michael Lashkevich 2023-02-19 19:47:57 UTC
(In reply to Andrey from comment #1)
> 
> *** This bug has been marked as a duplicate of bug 444569 ***

But that bug was marked as fixed for an _earlier_ version (5.23.3). It means that the bug reappeared, doesn't it? It isn't resolved for 5.24.4.
Comment 3 Andrey 2023-02-19 21:29:21 UTC
(In reply to Michael Lashkevich from comment #2)
> (In reply to Andrey from comment #1)
> > 
> > *** This bug has been marked as a duplicate of bug 444569 ***
> 
> But that bug was marked as fixed for an _earlier_ version (5.23.3). It means
> that the bug reappeared, doesn't it? It isn't resolved for 5.24.4.

The bug presented in 5.23.3 and the "Version Fixed In" is 5.26
Comment 4 Michael Lashkevich 2023-02-19 21:47:27 UTC
(In reply to Andrey from comment #3)
> The bug presented in 5.23.3 and the "Version Fixed In" is 5.26

But plasma 5.24 is LTS, so it won't be updated to 5.26 in most of distributions. What means its "long term support", if not correcting bugs?
Comment 5 Andrey 2023-02-19 22:10:06 UTC
You are right, I'll try to backport it:
https://invent.kde.org/plasma/plasma-desktop/-/merge_requests/1148#note_625226
Comment 6 Michael Lashkevich 2023-02-19 22:15:31 UTC
(In reply to Andrey from comment #5)
> You are right, I'll try to backport it:
> https://invent.kde.org/plasma/plasma-desktop/-/merge_requests/
> 1148#note_625226

Thank you very much!
Comment 7 Michael Lashkevich 2023-03-31 08:31:24 UTC
(In reply to Andrey from comment #5)
> You are right, I'll try to backport it:
> https://invent.kde.org/plasma/plasma-desktop/-/merge_requests/
> 1148#note_625226

I downloaded plasma 5.27.3 from a third-party repository and found that the issue has not really been solved. Indeed, if I set keyboard layouts globally, everything is all right. But if I set keyboard layouts per window (as I usually do), a new issue appears. Suppose, I have two windows Window1 and Window2. In Window1 I set Language2 (Russian in my case), while in Window2 I set Language3 (Hebrew). Then I change the focus from Window2 to Window1 and try to change languages with hot keys in Window1. The result is that the hotkeys for Language2 and Language3 change their places: Language2 hot key sets Language3 and vice versa.
Comment 8 Andrey 2023-03-31 09:27:07 UTC
Please file a separate detailed report about this specific case(In reply to Michael Lashkevich from comment #7)
> 
> I downloaded plasma 5.27.3 from a third-party repository and found that the
> issue has not really been solved. Indeed, if I set keyboard layouts
> globally, everything is all right. But if I set keyboard layouts per window
> (as I usually do), a new issue appears. Suppose, I have two windows Window1
> and Window2. In Window1 I set Language2 (Russian in my case), while in
> Window2 I set Language3 (Hebrew). Then I change the focus from Window2 to
> Window1 and try to change languages with hot keys in Window1. The result is
> that the hotkeys for Language2 and Language3 change their places: Language2
> hot key sets Language3 and vice versa.
Comment 9 Michael Lashkevich 2023-03-31 09:28:38 UTC
(In reply to Andrey from comment #8)
> Please file a separate detailed report about this specific case(In reply to
Ok.
Comment 10 Michael Lashkevich 2023-03-31 10:00:50 UTC
(In reply to Andrey from comment #8)
> Please file a separate detailed report about this specific case(In reply to
> Michael Lashkevich from comment #7)

Done: https://bugs.kde.org/show_bug.cgi?id=403284