Do the cursor keys work in Qt 5 line edit fields, e.g. Ctrl+F in Kate?

This bug seems to have two causes. Coming from https://bugs.kde.org/show_bug.cgi?id=343629 , there was the behaviour in the QTextEdit fields of konsole, Qt Creator and Kate in Vim-Mode to ignore the first key press after AltGr was pressed, so you had to press AltGr+S+S for one character left. This is solved with the patch from https://bugreports.qt.io/browse/QTBUG-34068 , which will hopefully land in the Qt 5.4.1 release.

While the patch fixes kate in vim input mode, it doesn't affect the behaviour in kate in normal input mode: AltGr+Anything key presses still get ignored completely, as described in the bug report.

As a side note, I can confirm that AltGr+S cursor navigation works as expected in kate's Ctrl+F search bar.

I might add, that AltGr+X still creates a tab character and AltGr+V still creates a new line as they should. But the most important keys don't work.

Still able to reproduce with kate from Applications 14.12.2.

Bug 338487 has some references to changes in Qt frameworks to fix it for Qt widgets. A similar fix could help for the KTextEditor widget.

you should know, that the keys work in qt applications and kde applications. The bug I am reporting here is really a new bug that was not there until the last update of kate, and is only in kate and kwrite in the writing area. So I doubt that the reported bugfix addresses the problem.

*** Bug 345297 has been marked as a duplicate of this bug. ***

I can confirm all observations on

Kate
Version 5.0.0
Using KDE Frameworks 5.10.0

I feel really crippled. I will consider to do all my editing in the latex editor that wasn't yet ported to KF5. ;)

Another observation: When I press the mod4 key to assign a custom short cut in

- kate: It gets totally ignored
- in non-ported kile: a message that the key would not be supported by Qt.

after quite some time, I tried out Kate again, and it works fine. I don't know it which version it was fixed, but here my current listed versions from pacman:

    extra/kate 15.04.3-1
    extra/katepart4 4.14.3-3
    extra/libkate 0.4.1-5

Just tested it again, too. I can confirm that everything works fine with the versions specified by Arne Döring. :)

*** This bug has been confirmed by popular vote. ***

I would like to reopen this bug report. I'm on opensuse tumbleweed with all updates installed.

I can still reproduce the bug. :( So in which way are your packages from pacman different? I don't think that kate is available from packman for my distro (ftp://ftp.gwdg.de/pub/linux/misc/packman/suse/openSUSE_Tumbleweed/Extra/x86_64/).

S | Name                   | Type        | Version     | Arch   | Repository
--+------------------------+-------------+-------------+--------+-----------
i | Kate                   | application |             | noarch | repo-oss  
i | ghc-highlighting-kate  | package     | 0.5.12-1.4  | x86_64 | repo-oss  
i | kate                   | package     | 15.04.3-1.1 | x86_64 | repo-oss  
i | kate-plugins           | package     | 15.04.3-1.1 | x86_64 | repo-oss  
i | kate4-parts            | package     | 4.14.3-2.2  | x86_64 | repo-oss  
i | libkate1               | package     | 0.4.1-23.3  | x86_64 | repo-oss  
i | libkatepartinterfaces4 | package     | 4.14.3-2.2  | x86_64 | repo-oss  
i | liboggkate1            | package     | 0.4.1-23.3  | x86_64 | repo-oss

(in case there's some confusion: „here my current listed versions from pacman“ meant „queried through pacman from the main repositories“, pacman is the Arch Linux equivalent of zypper, a command line package manager, and used to install packages from the main archlinux repositories at https://www.archlinux.org/packages/ - it has nothing to do with packman, the third party package repository for rpm-based distributions.)

At the time of writing, this is Qt 5.5.0, kate from KDE SC 15.04.3,  KDE Frameworks 5.12 and Plasma 5.3.2. Maybe openSuSE Tumbleweed ships an older version of Qt?

I configured my custom keyboard layout with arrow keys, BackSpace, Delete remapped to third-level as described in this bug report: https://bugreports.qt.io/browse/QTBUG-36565. While all keys except for BackSpace work with standard Qt widgets, they don't work with Kate/KWrite on my system (Manjaro - practically up-to-date with Arch).

But after I (experimentally) added {German (Neo 2)} layout to my keyboard layout list, both my 2 remapped layouts (dvp and ua) magically started working with Kate/KWrite, and BackSpace key started working with the Qt standard widgets! As soon as I remove the Neo 2 layout, third level special keys stop working. I tried adding other layouts, but none of them fixed the issue. So, my current workaround is to keep the Neo 2 layout in my keyboard settings :)

I think that there is some issue with QKeySequence and QAction shortcuts when the Neo 2 layout is absent. I rebuilt ktexteditor library in debug mode, added the following lines at the top of KateViewInternal::keyPressEvent (ktexteditor/src/view/kateviewinternal.cpp):
if (e->key() == Qt::Key_Right)
        qDebug() << "IGOR: RIGHT\n";
and this text was printed only when I used my third-level equivalent of the Right arrow key. When I used the actual Right arrow key, no text was printed, and cursor moved to the next character in Kate/KWrite window.
I found the following code in KTextEditor::ViewPrivate::setupEditActions (ktexteditor/src/view/kateview.cpp):
    a = ac->addAction(QLatin1String("move_cursor_right"));
    a->setText(i18n("Move Cursor Right"));
    ac->setDefaultShortcut(a, QKeySequence(Qt::Key_Right));
    connect(a, SIGNAL(triggered(bool)), SLOT(cursorRight()));
Replacing QKeySequence(Qt::Key_Right) with QKeySequence::MoveToNextChar didn't change anything.

So, apart from keeping the Neo 2 layout enabled, there is another ugly workaround: check the key in KateViewInternal::keyPressEvent and call the corresponding shortcut function. But I really hope that this will be fixed upstream in Qt. I'll add some info to the Qt bug report referenced at the top of this post.

Hey Igor,

thanks for your efforts. I have the following layouts in my keyboard settings (KDE controle module):
- de (neo2)
- us

However, I still experience this bug - even though neo2 is in the list. The neo arrow keys (under left hand) are still not working. Have you tested this? If so, am I right that my experience is contradicting yours?

I'm using latest opensuse tumbleweed. I'm not on my maschine right now, but could post further information if required once I'm back home.

Hi Robert,

I'm currently using XFCE desktop environment. I don't personally use any German layout, but adding Neo layout fixed issues with my custom-tweaked layouts (I added arrows, BackSpace, Delete to the third level in us(dvp) and ua). I had difficulties switching to the 4th level of Neo in XFCE. The only way I managed to do it was by invoking "setxkbmap de neo" from terminal. And then the arrow keys worked in medit (gtk-based text editor), but didn't work in Kate.

Then I switched to KDE 4 session and added several layouts. Despite having Neo in my KDE layout list, my other layouts' arrows worked in medit, but didn't work in Kate. After choosing Left Win for 5th level on the Advanced tab of KDE Keyboard settings, I was able to activate Neo's 4th level. And then arrow keys, BackSpace and others from the Neo layout worked in medit and in Kate.

So, there is an obvious inconsistency between XFCE and KDE 4 - everything is in reverse. I have no idea why my tests give such unexpected and confusing results.

I don't know why Neo layout doesn't work for you. Maybe it's because you have Qt 5.4.2 (https://software.opensuse.org/package/libQt5Core5), while Arch/Manjaro users have Qt 5.5.0.

Just remembered another thing that changed on my system besides the Qt version that could make a diference: because of https://bugs.kde.org/show_bug.cgi?id=339838 I changed my default X11 keyboard layout to de instead of neo. I didn't test wether that makes a difference in this situation.

This bug occurs again in Kate 15.08.3, KDE Frameworks 5.16.0, QT 5.5.1

Yes I can confirm. It is there again. But it does not appear in vi mode editing

I also can confirm, it seems like there is a neo regression introduced between Qt 5.5.0 and 5.5.1, see https://bugreports.qt.io/browse/QTBUG-34068, but I didn't test whether this specific issue also doesn't appear in 5.5.0.

There should be a test case that creates x11 events like those events emitted from the neo layout. These events should be send to a running kate session with some text and cursor position, and if the text did not change as expected, the test should fail. The developers need to see when they break the compatibility, I am a bit tired of broken compatibility, working again, broken … . I hope someone can do this, because I have never written a test case for qt or even kde applications.

I can confirm the bug using arch linux packages qt5-base 5.5.1-8, kate 15.12.1-1: the control keys (e.g., move cursor left) of the Neo2 keyboard layout do not work in Kate. However, they do work in Konsole (package konsole-15.12.1-1) and of course also in non-QT software on the other hand.

I have bisected the qtbase git repository and found the following:
1. This issue is not present in Qt 5.5.0 release.
2. The issue is introduced in this commit: http://code.qt.io/cgit/qt/qtbase.git/commit/?id=4067bbc24cf7a6d3058387225d9e67ad093991cd
3. And so the issue is present in Qt 5.5.1 release and in 5.5 branch.
4. The issue is fixed in this commit: http://code.qt.io/cgit/qt/qtbase.git/commit/?id=c7e5e1d9e01849347a9e59b8285477a20d82002b
5. And so the issue is not present in 5.6 branch.

So, the bad news is that this issue is likely to be present in Qt 5.5.2 release. The good news is that it will most likely be absent from Qt 5.6 release.

Then it should not be too long until this is resolved. The current release date is 9th February 2016 (http://wiki.qt.io/Qt-5.6-release).

Currently, I am using Kate 15.12.3 and Qt 5.6.0 and the error persists.

Indeed, the issue is back.
It was introduced before Qt 5.6.0 release - in the following commit:
https://code.qt.io/cgit/qt/qtbase.git/commit/?id=1e15b428b59c3134a0f584bfb303e95d0682e45d
The issue is currently present both in Qt 5.6 and 5.7 branches.
Fortunately, the commit that reintroduced the issue this time is extremely small. So, it should be easy to patch Qt and fix this issue.

@Those who are affected by this issue: Can you report / comment on this upstream and bug the Qt devs to find a fix? Maybe even you yourself can provide a fix for this, give you already identified the critical patches?

I investigated the relevant Qt code, but could not find a proper fix. Only a simple workaround, which is likely to break something else.
Created an issue on the Qt bug tracker: https://bugreports.qt.io/browse/QTBUG-53121.
@Those who are affected by this issue, feel free to vote there if you want the issue to be fixed soon.

I think I found the bug and added a patch to the Qt bug tracker ( https://bugreports.qt.io/browse/QTBUG-53121 ).

With this patch AltGr+ keys work for me in kate again. (Qt 5.6.0+patch; kate 16.04.1)
It would be good if you could also verify that this patch works for you.
And maybe even test it with different shortcuts/Layouts to make sure it does not introduce new bugs.

@Bernhard: You need to make a gerrit review request. This way, the patch gets much more attention. Often patches attached to bug reports just get ignored for loooong times.

Patch is merged => https://codereview.qt-project.org/#/c/162876/

Thanks that you fixed that! Awesome.