Created attachment 87756 [details] Screenshot showing "Detai&ls" artifact Launching Qt Creator in the just released Plasma 5 causes mysterious text issues: Namely that the "Details" button is in some places displayed as "Detai&ls" (see attached screenshot). This is apparently caused by the loading of KDEPlatformTheme.so into the process: The artifact doesnt' show up with QT_PLUGIN_PATH set to empty, or when manually removing KDEPlatformTheme.so Original bug report for Qt Creator: https://bugreports.qt-project.org/browse/QTCREATORBUG-12680
It seems KAcceleratorManager is actually to blame. Here's a stack trace where the '&' is injected into the QAbstractButton: 5 QAbstractButton::setText qabstractbutton.cpp 646 0x7ffff6eaf5ad 6 QAbstractButton::qt_metacall moc_qabstractbutton.cpp 241 0x7ffff71c68f9 7 Utils::DetailsButton::qt_metacall moc_detailsbutton.cpp 221 0x7ffff770cb9c 8 QMetaObject::metacall qmetaobject.cpp 308 0x7ffff56e4f23 9 QMetaProperty::write qmetaobject.cpp 2926 0x7ffff56ea773 10 QObject::setProperty qobject.cpp 3827 0x7ffff571f285 11 KAcceleratorManagerPrivate::calculateAccelerators 172 0x7fffe8425e8a 12 KAcceleratorManagerPrivate::manage 113 0x7fffe84271a3 13 KAcceleratorManager::manage 435 0x7fffe8427301 14 KCheckAccelerators::checkAccelerators 258 0x7fffe8be9183 15 KCheckAccelerators::autoCheckSlot 208 0x7fffe8bea1be 16 QMetaObject::activate qobject.cpp 3680 0x7ffff571ea2a 17 QMetaObject::activate qobject.cpp 3546 0x7ffff571e238 18 QTimer::timeout moc_qtimer.cpp 191 0x7ffff57af783 19 QTimer::timerEvent qtimer.cpp 255 0x7ffff572993f 20 QObject::event qobject.cpp 1222 0x7ffff5717faa ... <More>
Is there a reason why the button class does not support keyboard accelerators? If yes, how can I detect whether a button class refuses to support them?
The DetailsButton class is part of Qt Creator, and used only in contexts where shortcuts don't make much sense (Projects Pane). It paints on it's own (ignoring any system styles): http://code.woboq.org/qt5/qt-creator/src/libs/utils/detailsbutton.cpp.html#_ZN5Utils13DetailsButton10paintEventEP11QPaintEvent I guess this particular issue could be fixed by passing Qt::TextHideMnemonic to QPainter::drawText in DetailsButton::PaintEvent. I don't see, however, how one could force this 'from the outside', and it feels wrong to work around this in Qt Creator. The root problem is IMO that KDE 'injects' shortcut keys into applications. I'd have expected that it's the applications job to define sensible shortcuts where deemed necessary.
This btw causes one more regression in Qt Creator: The "Session" submenu in "File" doesn't work. This submenu contains a list of checkable QActions for available sessions (in a radio button group). If one now selects one menu entry Qt Creator compares the text() of the selected action with the list of available sessions... This fails if text() returns something different from what we set originally.
A different QStyle with a polish event could cause this too, even a different translation could put in a mnemonic. I'll move this to the right component within KDE, but personally I think the majority of the blame is QtCreator.
*** Bug 338421 has been marked as a duplicate of this bug. ***
(In reply to Christoph Feck from comment #6) > *** Bug 338421 has been marked as a duplicate of this bug. *** So KDE assigns an Alt+G accelerator to the "Go Back" button, even if it doesn't show any text. With KDE4, KCheckAccelerators::initiateIfNeeded was only called for KDE applications (KApplication). Now with KF5, any Qt application which loads libKF5XmlGui will call KCheckAcceleratorsInitializer::initiateIfNeeded, that's why QtCreator is affected. A workaround is to add [Development] AutoCheckAccelerators=false to kdeglobals, which prevents KDE from automatically adding accelerators.
A possibly related issue: https://bugs.kde.org/show_bug.cgi?id=345023
(In reply to Loïc Yhuel from comment #7) > (In reply to Christoph Feck from comment #6) [..] > A workaround is to add > [Development] > AutoCheckAccelerators=false > to kdeglobals, which prevents KDE from automatically adding accelerators. kdeglobals, from ~/.config not from ~/.kde/share/config
I can confirm the issue, and this doesn't only affect 1 application, but any Qt application that defines shortcuts with Alt+something. Please consider disabling this, at least for non-kde applications. I just came here because I was having severe problems implementing Qt shortcuts, and it was caused by this bug.
What I meant is that my application is creating shortcuts such as "Alt+F" which Kde assigns to a button, so they conflict and the shortcut no longer works. So basically, shortcuts within Qt applications might not work at all within KDE, depending on which buttons are shown and which shortcuts are created. This is why I believe it's a rather important issue. The problem is not only about the artifacts.
*** Bug 357418 has been marked as a duplicate of this bug. ***
This behavior is related to the code in KXmlGui, and not related to any code in KI18n, so reassigning for that reason alone to KXmlGui. Otherwise I have no idea what should be done here.
LMMS also triggers this : when built for Qt5, it creates a QMenu containing QActions which contain the recent files loaded. When you press one it uses its text() to load the file - and loading files like /&home/whatever doesn't work.
We have had reports of this same bug in LyX. See http://www.lyx.org/trac/ticket/10261.
Created attachment 102941 [details] Example of custom QTabWidget titles becoming shortcuts I'm also encountering this in my own program (https://github.com/cmdrkotori/mpc-qt). A playlist tab that gets an 'I' ampersanded conflicts with the default Alt-I take screenshot shortcut. This does not happen on a Windows build. If there were a way to turn this off at runtime without introducing extra dependencies (e.g. an environment variable), that'd be really good.
Would it be possible to remove this "feature"? It is super annoying. We are also fighting with ugly text artifacts in our application. We also cannot read back any text from the user interface, because whatever text we read from a label or menu entry is probably not what we initially wrote there. This has already cost me a lot of time to hunt down weird bugs where things somehow didn't work on KDE, but on all other platforms.
Hi, from my point of view, your are taking to much responsibility Dear KDE developers. The shortcuts are an application own business and intercepting that is bad architecture decision.
noob question: does KDE do that to make global shortcuts work or is that totally unrelated?
It is unrelated to global shortcuts. These accelerators are local shortcuts, they are accessed with Alt key while the window is active.
Here's how I solved it. It's a bit ugly. .pro file: LIBS += -ldl .c++ file: #include <dlfcn.h> void Helpers::disableSystemAccel(QWidget *what) { void *d = dlopen("libKF5WidgetsAddons.so", RTLD_LAZY); if (!d) return; typedef void (*DisablerFunc)(QWidget *); DisablerFunc setNoAccel; setNoAccel = reinterpret_cast<DisablerFunc>(dlsym(d, "_ZN19KAcceleratorManager10setNoAccelEP7QWidget")); if (setNoAccel) setNoAccel(what); dlclose(d); } Call this function in your object's constructor.
But, my project is in PyQt…
(In reply to Salvo "LtWorf" Tomaselli from comment #22) > But, my project is in PyQt… You should be able to do the same with ctypes.
This bug also affects me in the same way as it does to Janek; We made a little keyboard with buttons, where we had to add the same information as text and as another property. Also, as a GUI developer, if I don't assign a hot key to a given button, it is because it should not have a hot key. This also causes troubles on Qt Designer, where it eventually adds & to the labels on the .ui file being edited. cmdrkotori's solution should be available as a user configuration, imho.
This default behaviour also breaks GNU Octave: http://savannah.gnu.org/bugs/index.php?51851 http://savannah.gnu.org/bugs/index.php?51853 http://savannah.gnu.org/bugs/index.php?51905 And possibly http://savannah.gnu.org/bugs/index.php?51949
*** Bug 345023 has been marked as a duplicate of this bug. ***
*** Bug 353150 has been marked as a duplicate of this bug. ***
Just confirmed this behavior breaks custom actions in QGit 3.7.
AutoCheckAccelerators is breaking Falkon too, see: #394010
*** Bug 394010 has been marked as a duplicate of this bug. ***
It looks like the same applies to Clementine: https://github.com/clementine-player/Clementine/issues/5931
This bug also affects users of Retroarch's Qt Desktop Menu UI. https://github.com/libretro/RetroArch/issues/7112#issuecomment-418535423
FlightGear's Qt launcher is affected as well.
I would really love for this feature to be removed. I was modifying a window in qtdesigner. It was super frustrating until I figured out how to disable it.
Git commit 02b523bad09aab062355e46771889b0f3709692f by Albert Astals Cid. Committed on 12/01/2019 at 17:39. Pushed by aacid into branch 'master'. Make KCheckAccelerators less invasive for apps that don't directly link to KXmlGui Summary: BUGS: 337491 Test Plan: Ran qtcreator and it no longer has the & in Details Added some debug and checked that okular still gets the code called Reviewers: anthonyfieroni Reviewed By: anthonyfieroni Subscribers: davidedmundson, anthonyfieroni, kde-frameworks-devel Tags: #frameworks Differential Revision: https://phabricator.kde.org/D18204 M +36 -2 src/kcheckaccelerators.cpp https://commits.kde.org/kxmlgui/02b523bad09aab062355e46771889b0f3709692f