Bug 338487 - level5 modificator key combination not working properly
Summary: level5 modificator key combination not working properly
Status: RESOLVED UPSTREAM
Alias: None
Product: konsole
Classification: Applications
Component: keyboard (show other bugs)
Version: 2.99.900
Platform: Exherbo Linux
: NOR normal
Target Milestone: ---
Assignee: Konsole Developer
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2014-08-22 21:32 UTC by Bernd Steinhauser
Modified: 2015-02-02 16:11 UTC (History)
3 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 Bernd Steinhauser 2014-08-22 21:32:54 UTC
I'm using the 'neo' variant [1] of the german layout. One of the advantages of this layout is the use of a 'Mod4' (implemented as level5) key, which is represented by the <> (not present on the US keyboard layout) and the Alt Gr (aka right Alt) in the german keyboard layout. Mod4 can be used to access a number block and navigation keys embedded into the main section of the keyboard. I should note, that Mod3 (level3) works as expected.

When I changed to konsole based on KF5, there are some issues with this combination:
1. If Mod4 is pressed and released, the next keystroke is dropped
2. As a result, if one of the keys (i.e. Mod4+{e,d,s,f} = {Up,Down,Left,Right}) is used in combination with Mod4, the first event is dropped and—if Mod4 is held down—the second and following keystrokes are sent as expected
3. Combinations involving Mod4 won't work (i.e. Shift+Left (in QWERTY: Right Alt+Shift+s)), although the normal shortcuts work properly

[1] http://www.neo-layout.org/

How to reproduce:
1. Open konsole
2. setxkbmap yourlayout (just so you can easily go back with the cursor keys)
3. setxkbmap de neo
4. Press rAlt and release, then press some letter or number key
5. Try to use right Alt + s (which should be Left), notice that it only works the second time if rAlt is held
6. Open a second Tab
7. Try to use Shift + rAlt + s (should switch tabs)
8. setxkbmap yourlayout (to switch back)
Comment 1 Bernd Steinhauser 2014-08-23 13:37:51 UTC
I just noticed, that this issue is present in other KF5-based applications, too, i.e. infocenter, systemsettings, dolphin.

However, in a "pure" Qt5 application like qupzilla (built with Qt5 of course), it does not occur. So to me it looks like this is a KF5-bug, rather than a konsole-bug. Can't tell, though, which one.
Comment 2 Bernd Steinhauser 2014-09-12 19:16:22 UTC
After a chat with sebas on IRC, it seems like this is caused by modified behaviour in Qt5, which causes KF5-based stuff to not properly work with modifiers (also present with the "Meta" key for shortcuts, see review 118581 [1]).

So it's not a konsole bug. The shortcut part most likely belongs to kglobalaccel, but I don't know which framework the text input part would belong to.
In the meantime, the bug might be reassigned to kglobalaccel?

[1] https://git.reviewboard.kde.org/r/118581/
Comment 3 Bernd Steinhauser 2015-01-11 17:55:48 UTC
Tried this on a Fedora system and can reproduce it there as well.
Comment 4 Florian Jacob 2015-01-26 09:08:49 UTC
Just got the update to the KF5 version of konsole on Arch Linux through the update to KDE Applications 14.12 while still running KDE4. Exactly the same behaviour here, thanks for the in-depth analysis of what's actually going wrong, Bernd Steinhauser!

Now trying to downgrade to the KDE4 version to be able to work with konsole again.
Comment 5 Bernd Steinhauser 2015-01-29 06:25:53 UTC
However, I have to revert one observation, I made: I does apply (at least to some) Qt5 applications as well. Noticed this in Cantata and in Qupzilla.

For the latter, I found, that the widget for the URL is not affected, the rest seems to be. The same behaviour applies to konqueror (from scm).

So I guess this is a bug in qtbase after all. I'll report a bug there.
Comment 6 Florian Jacob 2015-01-31 17:14:53 UTC
I just commented to this bug report, which seems to be related, with my newest research: https://bugreports.qt.io/browse/QTBUG-34068

When building a plain Qt Application, every type of text input, TextEdit as well as LineEdit, works fine and just as expected. The behaviour seems to appear only in some complex uses of multi-line TextEdits, as it appears in kate and QtCreator as well. So the bug doesn't seem to be in the very basic QTextEdit, but maybe in the way application listen to KeyEvents from the QTextEdit?
Comment 7 Florian Jacob 2015-02-01 14:58:40 UTC
I rebuilt qtbase with the patch from https://bugreports.qt.io/browse/QTBUG-34068 which isn't included in Qt 5.4.0, this fixes our issues. :) Well, at least in konsole and QtCreator, but not in kate non-vim-mode. Just found there's allready a bug report for kate, I'll will report there to help out: https://bugs.kde.org/show_bug.cgi?id=343629

So this bug here will probably be fixed with the next Qt release, Qt 5.4.1.
Comment 8 Bernd Steinhauser 2015-02-02 16:11:53 UTC
Indeed, the given patch fixes the issue. So I'll close this as resolved, upstream.
For a solution refer to
https://codereview.qt-project.org/#/c/102007/