"Those who don't know history are destined to repeat it." The title is intentionally chosen very similar to this issue: https://bugs.kde.org/show_bug.cgi?id=337491 *This is because the issue behaves exactly the same - but for Qt6 instead of Qt5.* My Qt version is 6.8.1. I am not 100% sure if kglobalaccel is responsible for the problem but kxmlgui of the reference issue was seemingly also not correct. Someone there mentioned the KAcceleratorManager as cause but I did not found this as Product to select. The problem hit me at a custom Pyside 6 application. Only reason it did not crash was because the exception was caught: ``` Traceback (most recent call last): File "[...]editor/dialogs.py", line 995, in buttonClicked self.worker = ConsistencyWorker(self.Ctrl.currents, CMT_NAME_TO_PRODUCT_STRING_MAP[product], self.Ctrl.metadata) ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^^^^^^^^^ KeyError: '&SmartA' ``` Just like in the original issue the problem could be workarounded by adding ``` [Development] AutoCheckAccelerators=false ``` to .config/kdeglobals As developer I still can't imagine how anyone could come up with "Let's inject ran&dom Qt mnemoni&cs into UI objects of 3rd party ap&plications! Like what ha&rm could an i&nvisible random am&persand do in the tex&t value of a butto&n?" But maybe I haven't fully grasped the sense of this feature. From my perspective it is just asking for problems.
Small addition: Maybe my bug report sounded a bit too harsh. I really love open source projects and you are doing great work at KDE! However, the bug was not easy to track down and I was asking myself how many people have a problem related to this bug and have no possibility to actually debug it.
Indeed the platformtheme links kxmlgui (technical info is uses it in a singleplace action collection in kdirselectdialog.cpp can probably go?) you could also add the config to $(nameofyourapprc) If I interpret that correctly you are using the UI strings to do look up. That looks like a code smell to me as that cannot work with for example translated strings. I recommend using something else to identify widgets.
> As developer I still can't imagine how anyone could come up with "Let's inject ran&dom Qt mnemoni&cs into UI objects of 3rd party ap&plications! Like what ha&rm could an i&nvisible random am&persand do in the tex&t value of a butto&n?" > >But maybe I haven't fully grasped the sense of this feature. From my perspective it is just asking for problems. Because things are more complex than they might seem. It's code written for KDE applications that (very indirectly) leaks into other applications as well. As you can see from https://bugs.kde.org/show_bug.cgi?id=337491 a long time ago a change was made to fix this for non-KDE applications, but it appears that for yet unknown reasons that doesn't work any more with Qt6
Git commit 29803f0a2cb37f12778b39f345eb3c6e7a4bf7d0 by Nicolas Fella, on behalf of Christoph Cullmann. Committed on 07/02/2025 at 13:16. Pushed by nicolasfella into branch 'master'. Instantiate accelerator checking only on KMainWindow creation Currently this is done as a startup function on library load, meaning it is active for everything that loads the KXmlGui library, even when indirectly via the plasma-integration plugin. We have some code that tries to prevent this, but that doesn't seem to work reliably (anymore). M +24 -79 src/kcheckaccelerators.cpp M +3 -0 src/kcheckaccelerators.h M +4 -0 src/kmainwindow.cpp https://invent.kde.org/frameworks/kxmlgui/-/commit/29803f0a2cb37f12778b39f345eb3c6e7a4bf7d0
> If I interpret that correctly you are using the UI strings to do look up. That looks like a code smell to me as that cannot work with for example translated strings. I recommend using something else to identify widgets. @David Redondo It is not particular nice but it isn't my code either. It is a rather simple GUI utility which generically generates the buttons with a common slot and re-identifies them by name. I already changed the code to use setObjectName/objectName instead. However, I don't know where else it could pop up. @Nicolas Fella thanks for looking into this. After all it is a bug without a doubt and I hope you are successful fixing it for Qt6.
Changing Importance as this is not a crash
Nico, is there anything left to do here?
I don't think so, but I haven't extensively tested it