Version: (using KDE 4.4.0) Installed from: Gentoo Packages I just wanted to close KLinkStatus using Ctrl+Q. But all I get is a popup saying that this shortcut is ambiguous and that I should reassign it. But it doesn not tell me with what shortcut it is in conflict. The only item in KLinkStatus’ shortcuts which holds Ctrl+Q is, of course, Exit. So this is what I did to test the issue for reproducability: - Make sure Ctrl+Q brings the warning about ambiguity :) - set the shortcut for Exit to "none", now Ctrl+Q works as expected - start the app again, hit Ctrl+Q, it still works - start the app again, look into shortcut settings, and there Ctrl+Q is listed again, assigned to Exit - hit cancel, Ctrl+Q still works - start the app again, reset shortcuts to default, hit OK - now the warning is back again. I have a similar issue in Krusader: I manually assigned Alt+C to “Compare by content”, Krusader’s shortcuts dialogue accepted it without a problem. But when I press it, I get the same popup about ambiguity. I’ve looked through all shortcut lists in system settings, but couldn’t find Alt+C assigned anywhere. At some point in the past it already worked, but now I’m in a newly set-up environment and there it is again. So here again, it would be very helpful if the popup actually told about what is ambiguous. Cheers
Other bugs deal with the same symptoms, but on app level (such as Bug 228194 for Konqueror and Bug 188764 for Kate). But I reckon the’re all due to KDE’s way of handling shortcuts in the first place, so the real cause probably lies within KDE’s handling of hotkeys in gereral. (I’m not sure though whether to file this for khotkeys or kdelibs, so please CC if necessary). I just encountered in in Kate myself, trying to compile something. Since it impacts a wide area of use cases, it really needs fixing. A good solution would be to have local hotkeys (i.e. those configured for the current application) get priority over global hotkeys.
*** Bug 299797 has been marked as a duplicate of this bug. ***
Hi Frank, since there's two of us now, would you consider spending your 20 votes on this?
I had some big problems finding out the conflict for Shift-Insert (paste) in the console part in dolphine (activaded by pressing F4), and to be honest I still don't really know what the conflict was. I just deleted one paste mapping and it started to work. I'm not sure about letting local have higher priority than global. I think some key combinations are meant to always work regardless of what window has the focus, like PrintScreen to launch a screenshot tool. But a priority flag would solve that. And then instead of doing nothing, the "Ambiguous keyboard shortcuts" could perhaps present the a choice for which to set the flag. If the global scope lack knowledge about which local shortcuts might exist we could make the priority flag a date (in seconds) when the it was set. Freshest flag then wins. Zero or lack of a flag shoud trigger the setting dialog, but obviously only the local applications should do this as a global can have priority over an unknown amout of hotkeys.
*** This bug has been confirmed by popular vote. ***
I too am running into this issue with the console in Dolphin. Shift+Insert creates a popup and I have no idea where to look for the conflict. Should I create a new bug report for this?
Shift+Insert is both used in Dolphin and in the Konsole part. If you have Dolphin with Terminal panel open, remove or change the Shift+Insert shortcut in Dolphin; you can still use Ctrl+V for Paste.
Hi, kdelibs (version 4 and earlier) is no longer maintained since a few years. KDE Frameworks 5 or 6 might already have resolved this bug. If not, please re-open against the matching framework if feasible or against the application that shows the issue. We then can still dispatch it to the right Bugzilla product or component. Greetings Christoph Cullmann