Bug 337491

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

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