When the KDE plugins are loaded in qt5 designer, ampersand shortcuts are dynamically added/re-assigned in non-KDE widgets, and also in the designer interface itself. For instance, after creating a new Qt MainWindow form and adding a menu "&Play", the title is immediately changed to "Pl&ay". This seems to be because it clashes with the "P" in the Property Editor dock widget (which has also had an ampersand shortcut dynamically added to it by the KDE plugins). When the KDE plugins are disabled, this behaviour does not occur. Reproducible: Always Steps to Reproduce: 1. open qt5 designer with kde plugins enabled 2. create a new, non-KDE form 3. add a new menu with an ampersand shortcut that clashes with an existing one in the designer interface Actual Results: the clashing ampersand shortcut is changed Expected Results: the ampersand shortcut should remain as entered by the user This problem was originally reported on the Qt bug tracker: https://bugreports.qt.io/browse/QTBUG-44786. Tested versions: Qt Designer 5.4.1 kdesignerplugin 5.7.0
I'm having an issue with QtCreator 3.4.0 on Kubuntu 15.04 (KDE Framework 5.9, Plasma 5.3 installed from backports) which may be caused by this bug. Some of QtCreator keyboard shortcuts cause actions which are not set in settings. These are steps to reproduce: Problem with Alt+S: 1. Open an SVN-based project in QtCreator. Open a file in the editor. 2. Press Alt+S, then Alt+D. Result: On Alt+S the project is built and run. Alt+D is not waited for. Expected result: On Alt+D the currently open file should be `svn diff`ed. There's a similar problem with Alt+G: 1. Open an git-based project in QtCreator. Open a file in the editor. 2. Press Alt+G, then Alt+D. Result: On Alt+G the QtCreator jumps to another file. Alt+D is not waited for. Expected result: On Alt+D the currently open file should be `git diff`ed. I'm not having this behavior in fvwm on the same system or if I run QtCreator with QT_PLUGIN_PATH="" environment variable. There's a QtCreator bug report with more details: https://bugreports.qt.io/browse/QTCREATORBUG-14445
This Bug seems to be way more serious than I thought. I had to debug an application that was misbehaving on KF5 and figured out that the text assigned to buttons are changed by KDE during runtime. So settings button->setText("Some Text") and later doing something like button->text() == "Some Text" will fail as the new text is something like "&Some Text). I know that this is not a good practice comparing strings like that but this behavior will probably break many applications on KF5 that are working fine on all other Platforms supported by Qt. I don't think that this is acceptable.
This also causes https://bugs.kde.org/show_bug.cgi?id=337491
This affects also the QWizardPage title. e.g. "Stammdaten" is automatically changed to "St&ammdaten"
Created attachment 93836 [details] Automatically added ampersand in QWizardStep title
Just wanted to add to the comments made by Alexander, this is not just a designer issue, perhaps the bug title should be changed. Debugging an issue in GoldenCheetah I created a short example test case: https://github.com/GoldenCheetah/GoldenCheetah/issues/1852#issuecomment-188658910 This shows that the problem surfaces when a QAction* is passed back to a triggered event at which point the text has an accelerator, although the tooltipText() remains correct.
Just some further detail: This only happens for a Qt application running inside KDE. The QAction returns the correct text until the application is running and the menu exists. i.e. adding the menu item and returning the QAction returns the original text, once the application is running and the actual window and menu exists then querying the string returns text with accelerators.
I can confirm this bug. Today I got hit by the same bug when compiling and running a Qt5 application using the Qt5 development libs that comes with Opensuse. When recompiling the same application with Qt4 (compiled from source) everything works fine. My system: Opensuse Leap 42.2 & Plasma 5. Can we at least change the status to "confirmed"? Any news about when this is going to be fixed?
Any news?
*** This bug has been marked as a duplicate of bug 337491 ***