Bug 322027 - Problem in modifier key behavior with multiple keyboard layouts in upcoming Qt 4.8.5
Summary: Problem in modifier key behavior with multiple keyboard layouts in upcoming Q...
Status: RESOLVED DUPLICATE of bug 309193
Alias: None
Product: kate
Classification: Applications
Component: part (show other bugs)
Version: Git
Platform: Compiled Sources Linux
: VHI major
Target Milestone: ---
Assignee: KWrite Developers
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2013-07-06 09:32 UTC by Chusslove Illich
Modified: 2015-10-15 16:43 UTC (History)
6 users (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Chusslove Illich 2013-07-06 09:32:49 UTC
Things with Ctrl+letter shortcuts get slightly complicated when there are
multiple keyboard layouts in rotation, so I will limit this to the case of
one Latin layout and one non-Latin layout in XKB rotation. When a Ctrl+Latin
letter shortcut is to be activated, the user will press Ctrl+key on which
that letter resides on the Latin layout. The expectation is that this should
activate the shortcut no matter what the currently selected layout is and no
matter the XKB order of layouts. Up to Qt 4.8.4, this worked if the first
layout was the Latin layout, but not if the first layout was the non-Latin
layout. Then came this fix to make it work also when the first layout is the
non-Latin layout:

https://bugreports.qt-project.org/browse/QTBUG-15319

Unfortunatelly, in my tests this leads to worse-than-before behavior in
KWrite/Kate and katepart-using applications (e.g. Kile), as I mentioned in
the last comment: when the non-Latin layout is selected, Ctrl+Latin letter
shortcut does not work no matter the XKB order of layouts, and
Ctrl+Shift+Latin letter triggers what Ctrl+Latin letter was supposed to
trigger. When I revert the patch from the bug report, the 4.8.4 behavior is
recovered.

I have no idea what is going on here, so I'm bringing this to attention of
Kate maintainers, in hope that they can make a more intelligent assessment.
Is it a plain regression in Qt, is it that Kate code is doing something
funky, etc.


Reproducible: Always
Comment 1 Coacher 2013-07-23 20:08:44 UTC
I confirm this bug on KDE 4.10.5 with Qt 4.8.5 on Gentoo amd64.

The problem is bigger than just katepart applications: my Konqueror shortcuts stopped working altogether with non-latin keyboard layout, as well as Dolphin shortcuts. I guess it's every single KDE application that is affected, though I cannot test all of them, of course, but the core ones like Dolphin, Konqueror, Kwrite don't recognize shortcuts when non-Latin layout is enabled anymore.

Please fix.
Comment 2 victormg 2013-07-29 07:58:21 UTC
Confirm
OpenSUSE 12.3 x86 KDE 4.10.5 Qt 4.8.5
Comment 3 StanislavArch 2013-08-28 11:48:21 UTC
It's QT bug
https://bugreports.qt-project.org/browse/QTBUG-32908
And main discussion here:
https://bugs.kde.org/show_bug.cgi?id=309193

Please vote.
Comment 4 Jekyll Wu 2013-08-28 13:57:29 UTC

*** This bug has been marked as a duplicate of bug 309193 ***
Comment 5 Barbaros Akkurt 2013-10-15 11:49:39 UTC
Hello,
I am getting the same behaviour when using Turkish Q (works perfect) and Turkish F (erroneous). It is quite nice with Turkish Q, because all Latin letters are in the same place and no problem occurs. However, I can type quite fast in Turkish F, so when I switch to this layout, the save (Ctrl+S) keeps the S key of the original Q layout, not the S key of the Turkish F layout. I have found an interesting thing with the top menu, the first ALT+letter works with the Latin layout, but the selection letter can be different, and works with the Turkish-F layout. I like word wrapping, so I hit ALT-T (for Tools) according to the Latin letter, and then hit W for Word Wrap with the corresponding key in Turkish-F layout. It is not very frustrating, but if the key combinations like CTRL+S, CTRL+C and CTRL+V would be converted into the active keyboard layout, I would be grateful.
Thank you.

(In reply to comment #0)
> Things with Ctrl+letter shortcuts get slightly complicated when there are
> multiple keyboard layouts in rotation, so I will limit this to the case of
> one Latin layout and one non-Latin layout in XKB rotation. When a Ctrl+Latin
> letter shortcut is to be activated, the user will press Ctrl+key on which
> that letter resides on the Latin layout. The expectation is that this should
> activate the shortcut no matter what the currently selected layout is and no
> matter the XKB order of layouts. Up to Qt 4.8.4, this worked if the first
> layout was the Latin layout, but not if the first layout was the non-Latin
> layout. Then came this fix to make it work also when the first layout is the
> non-Latin layout:
> 
> https://bugreports.qt-project.org/browse/QTBUG-15319
> 
> Unfortunatelly, in my tests this leads to worse-than-before behavior in
> KWrite/Kate and katepart-using applications (e.g. Kile), as I mentioned in
> the last comment: when the non-Latin layout is selected, Ctrl+Latin letter
> shortcut does not work no matter the XKB order of layouts, and
> Ctrl+Shift+Latin letter triggers what Ctrl+Latin letter was supposed to
> trigger. When I revert the patch from the bug report, the 4.8.4 behavior is
> recovered.
> 
> I have no idea what is going on here, so I'm bringing this to attention of
> Kate maintainers, in hope that they can make a more intelligent assessment.
> Is it a plain regression in Qt, is it that Kate code is doing something
> funky, etc.
> 
> 
> Reproducible: Always