Bug 303504 - Conflicting keyboard shortcuts defined by Kate and KDevelop
Summary: Conflicting keyboard shortcuts defined by Kate and KDevelop
Status: CONFIRMED
Alias: None
Product: kdevelop
Classification: Applications
Component: UI: all modes (other bugs)
Version First Reported In: git master
Platform: Compiled Sources Linux
: NOR minor
Target Milestone: ---
Assignee: kdevelop-bugs-null
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2012-07-14 00:16 UTC by Mateusz Loskot
Modified: 2019-07-20 12:04 UTC (History)
3 users (show)

See Also:
Latest Commit:
Version Fixed/Implemented In:
Sentry Crash Report:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Mateusz Loskot 2012-07-14 00:16:38 UTC
There are many keyboard shortcuts defined by both, Kate component and KDevelop itself.

I asked on IRC if it would be possible to clean it up, so there are no or few conflicts?
Nicolás suggested it seems complicated, and I suppose it is indeed.
Then, it seems pointless to report shortcuts like CTR+- or F10 in UI (e.g. in menu labels) when they don't work, does it?

IMO, it's an issue and it would be helpful if possible to clean it up and declare only those shortcuts that work without conflicts.

Reproducible: Always
Comment 1 RJVB 2019-07-20 12:04:59 UTC
Just had a run-in with this, Kate's unfamiliar-to-me Ctrl-/ shortcut for "toggle comment" conflicting with the same shortcut for the switch-to-buddy feature.

Curiously I now have 2 entries for "Toggle comment" in the "katepart" list of shortcuts; the other already had a custom shortcut set to None.

Ideally the programmatic way to set a shortcut with choices to fail if it already exists or else to replace the existing shortcut. It should also not be possible for default shortcuts to register if an identical user-defined shortcut exists.

The only really complicating factor I can think of here is if the function that sets the shortcut doesn't have access to the current collection of shortcuts (which may be context-specific, etc).

Given that, the warning dialog could/should be redesigned, such that
1) it shows the other action(s) triggered by the same shortcut (presumable in the same context)
2) lets the user indicate which action s/he intented to invoke.