Created attachment 134075 [details] A short video to demonstrate the issue SUMMARY I couldn't set shortcut keys in "Custom Shortcuts" setting because it failed to record my key presses. STEPS TO REPRODUCE 1. Open "Custom Shortcuts" tab in KDE System Settings. 2. Create a new shortcut or edit an existing one. 3. Switch to the "Trigger" tab, activate the shortcut button following "Shortcut:" text. 3. Press desired key or key combination to set the shortcut. OBSERVED RESULT Key presses were not recorded. The shortcut button still showed "None". A line of error "kf.guiaddons: Cannot record without a window" appeared in stderr every time when pressing the shortcut button. EXPECTED RESULT Key presses are correctly recorded. SOFTWARE/OS VERSIONS Operating System: Arch Linux KDE Plasma Version: 5.20.4 KDE Frameworks Version: 5.77.0 Qt Version: 5.15.2
Hi. The same thing is happening to me when I want to configure keyboard shortcuts from KDE Menu Editor. KDE Neon (Testing) KDE Frameworks Version: 5.77.0
This bug report is about the "Custom Shortcuts" page in System Settings, not the different system used by the "Shortcuts" page and KMenuEdit.
In both cases from System Settings or KDE Menu Editor the same thing happens, when you click on the field to enter a new key combination, the field does not react and it keeps showing "none" (or old key combination) and new key combination is not entered. The problem is recent and happens in both cases at the same time. The source of the problem should be the same, or is it really a very strange coincidence.
And I get the same error with kmenuedit: kf.guiaddons: Cannot record without a window
No, the sources of the problem are different. This KCM has a totally custom implementation, while KMenuEdit and the Shortcuts KCM use KGlobalAccel Please file a new bug for your issues with the kglobalaccel-based issue seen in KMenuEdit and the Shortcuts page, which doesn't have anything to do with this bug report. :)
*** Bug 430460 has been marked as a duplicate of this bug. ***
If they have different system shortcuts, then you look for the source of the problem in Qt/GUI and the field type for shortcut input. I don't believe in these kinds of coincidences.
I'm a KDE developer familiar with the code in question and I'm telling you that they are unrelated. If you don't want to file a new bug report to track your issue, that's fine, but then we won't be able to investigate it and hopefully provide a fix.
I've edited: ~/.config/kglobalshortcutsrc ~/.config/khotkeysrc and changed the hotkey to what I want. When I reboot and log into tty F1 and look at the files they are what I edited. When I login to the gui the hotkey is replaced with "none" in both files. As a kludge I did this: sudo chattr +i ~/.config/kglobalshortcutsrc sudo chattr +i ~/.config/khotkeysrc to make the files immutable. Reboot and login now keeps the hotkeys and they work. I don't know what is overwriting the files on login. I'm on up to date kde neon plasma.
(In reply to Jeff Tratt from comment #9) > I've edited: > ~/.config/kglobalshortcutsrc > ~/.config/khotkeysrc > and changed the hotkey to what I want. When I reboot and log into tty F1 and > look at the files they are what I edited. When I login to the gui the hotkey > is replaced with "none" in both files. > > As a kludge I did this: > sudo chattr +i ~/.config/kglobalshortcutsrc > sudo chattr +i ~/.config/khotkeysrc > to make the files immutable. Reboot and login now keeps the hotkeys and they > work. I don't know what is overwriting the files on login. > > I'm on up to date kde neon plasma. I did just that, but only editing khotkeysrc. Unfortunately, I couldn't change it manually, as it gets rewritten as soon KDE starts.
(In reply to Heu Fui from comment #10) > I did just that, but only editing khotkeysrc. Unfortunately, I couldn't > change it manually, as it gets rewritten as soon KDE starts. Edit the file ~/.config/khotkeysrc then in terminal enter sudo chattr +i ~/.config/khotkeysrc Verify the file is immutable: lsattr ~/.config/khotkeysrc ----i---------e----- ~/.config/khotkeysrc The "i" validates the file is immutable. You may need to edit both files for this kludge to work. I didn't try editing only the one file.
(In reply to Jeff Tratt from comment #11) > (In reply to Heu Fui from comment #10) > > I did just that, but only editing khotkeysrc. Unfortunately, I couldn't > > change it manually, as it gets rewritten as soon KDE starts. > > Edit the file ~/.config/khotkeysrc > then in terminal enter > sudo chattr +i ~/.config/khotkeysrc > > Verify the file is immutable: > lsattr ~/.config/khotkeysrc > ----i---------e----- ~/.config/khotkeysrc > The "i" validates the file is immutable. > > You may need to edit both files for this kludge to work. I didn't try > editing only the one file. Thank you. Will do that. When all else fails, manual editing files is a great solution.
(In reply to Heu Fui from comment #12) > Thank you. Will do that. When all else fails, manual editing files is a > great solution. You're welcome. You will need to run the following to make the files editable in the future: sudo chattr -i ~/.config/kglobalshortcutsrc sudo chattr -i ~/.config/khotkeysrc the '-i' will remove the immutable bit. As immutable nothing can edit these files ;)
(In reply to Jeff Tratt from comment #13) > (In reply to Heu Fui from comment #12) > > Thank you. Will do that. When all else fails, manual editing files is a > > great solution. > > You're welcome. You will need to run the following to make the files > editable in the future: > sudo chattr -i ~/.config/kglobalshortcutsrc > sudo chattr -i ~/.config/khotkeysrc > > the '-i' will remove the immutable bit. As immutable nothing can edit these > files ;) Thanks again! You've pointed out in the right direction. Did exactly what you proposed and now my much needed custom shortcut is finally working. Will keep those files immutable until this bug is solved.
Operating System: Arch Linux KDE Plasma Version: 5.20.4 KDE Frameworks Version: 5.77.0 Qt Version: 5.15.2 Same problem. The error in console is: "kf.guiaddons: Cannot record without a window"
(In reply to Nate Graham from comment #5) > No, the sources of the problem are different. This KCM has a totally custom > implementation, while KMenuEdit and the Shortcuts KCM use KGlobalAccel > > Please file a new bug for your issues with the kglobalaccel-based issue seen > in KMenuEdit and the Shortcuts page, which doesn't have anything to do with > this bug report. :) But looks like "kcmshell5 khotkeys" would also produced the same error. Looking closer, I think the bug is in kxmlgui, when it is ported to KeySequenceRecorder. I think the issue is when it is constructed, the widget may not yet added to a window. So pass the window to KeySequenceRecorder in constructor doesn't work. Sent a merge request to fix this.
A possibly relevant merge request was started @ https://invent.kde.org/frameworks/kxmlgui/-/merge_requests/34
*** Bug 430495 has been marked as a duplicate of this bug. ***
*** Bug 430481 has been marked as a duplicate of this bug. ***
I just found another workaround. All you do is to go to the System Settings > Shortcuts, and on the search field you look up the custom shortcut you need to add/change. On the results box, press the desired result and click the corresponding buttons either to add/change shortcut or to add another. Your shortcut combination will now be registered and accepted. Example: https://i.imgur.com/rWKvvWy.png
Thank you, Heu Fui, your workaround of doing a search in the standard shortcuts menu worked for me.
(In reply to Heu Fui from comment #20) > I just found another workaround. > > All you do is to go to the System Settings > Shortcuts, and on the search > field you look up the custom shortcut you need to add/change. On the results > box, press the desired result and click the corresponding buttons either to > add/change shortcut or to add another. Your shortcut combination will now be > registered and accepted. > > Example: https://i.imgur.com/rWKvvWy.png Great find, Heu Fui. Your solution survived reboot and kept the change I made manually. Much better solution! Thank you.
Git commit 1bd9ac05b0eed3582937829150b31ea48fd95bb0 by Xuetian Weng, on behalf of Weng Xuetian. Committed on 22/12/2020 at 05:19. Pushed by xuetianweng into branch 'master'. Fix key recording by setWindow before capture starts. It is common that during the construction of widget, it is not yet added to a window. Thus windowHandle will simply return null in this case. Always set the window to before the capture starts. M +1 -0 src/kkeysequencewidget.cpp https://invent.kde.org/frameworks/kxmlgui/commit/1bd9ac05b0eed3582937829150b31ea48fd95bb0
*** Bug 430710 has been marked as a duplicate of this bug. ***
(In reply to Nate Graham from comment #8) > I'm a KDE developer familiar with the code in question and I'm telling you > that they are unrelated. If you don't want to file a new bug report to track > your issue, that's fine, but then we won't be able to investigate it and > hopefully provide a fix. khotkeys was changed to use KGlobalAccel in this commit: https://invent.kde.org/plasma/khotkeys/-/commit/f42a8446be7657ec3397be7fc253f7f64cb31392
and kmenuedit too with this commit: https://invent.kde.org/plasma/kmenuedit/-/commit/507bc58bf3e8704cdb4eab51ca16a2eb28299bb6
Hah I totally missed that it was ported to kglobalaccel. My bad, sorry.
Entering new shortcuts now works here in KDE Neon (Testing). Thanks to all the developers. @Nate Graham, sorry for my attitude. Regardless of what was causing the problem, perhaps I should have opened the new report from the beginning just in case.
*** Bug 430635 has been marked as a duplicate of this bug. ***
*** Bug 431028 has been marked as a duplicate of this bug. ***
*** Bug 431225 has been marked as a duplicate of this bug. ***
when can we expect the fix to be released?
3 days :)
*** Bug 431243 has been marked as a duplicate of this bug. ***
> 3 days :) Does this mean that fix will land today in KDE Neon? :)
tried it after yesterdays update ... no joy ;)
In general, for the KDE Neon User Edition, it would be nice if small, non-breaking bugfixes like this one could be released earlier, for example together with or one day after Neon Testing.
Guys,does it work now for you?
I created a new shortcut today and it worked fine. Thanks to everyone who contributed.
I can also confirm that it works again :)
I tried it and it doesn't work for me.
(In reply to Toadfield from comment #41) > I tried it and it doesn't work for me. Could you describe more detailed, please? Is the behaviour you are experiencing still exactly the same as in the issue description? Is your system up-to-date? Which distribution are you using?
I can cofirm .. fixed it for me
(In reply to Manuel Geißer from comment #42) > (In reply to Toadfield from comment #41) > > I tried it and it doesn't work for me. > > Could you describe more detailed, please? Is the behaviour you are > experiencing still exactly the same as in the issue description? > Is your system up-to-date? Which distribution are you using? It is the same thing and I use Manjaro and my system is up to date.
(In reply to Toadfield from comment #44) > It is the same thing and I use Manjaro and my system is up to date. Then I think you should probably report this upstream in the Manjaro packages bug tracker.
Updated Arch Linux. I've tested it and it's working. Thank you all.
(In reply to Toadfield from comment #41) > I tried it and it doesn't work for me. If you tried the kludge I recommended which sets the files to immutable you will need to undo that. Run the following to make the files editable: sudo chattr -i ~/.config/kglobalshortcutsrc sudo chattr -i ~/.config/khotkeysrc the '-i' will remove the immutable bit so the system can edit these files.