Summary: | shortcut clash in default settings: [F7]: build active target (kdevelop) and toggle command line (kate) | ||
---|---|---|---|
Product: | [Frameworks and Libraries] kdelibs | Reporter: | Daniel Franke <franke.daniel> |
Component: | kedittoolbar | Assignee: | KDevelop Developers <kdevelop-devel> |
Status: | RESOLVED DUPLICATE | ||
Severity: | normal | ||
Priority: | NOR | ||
Version: | SVN | ||
Target Milestone: | --- | ||
Platform: | unspecified | ||
OS: | Linux | ||
Latest Commit: | Version Fixed In: |
Description
Daniel Franke
2004-04-23 07:51:47 UTC
Sigh. We are never going to be fully rid of this problem. In this case I'm pretty sure we were even using this shortcut before katepart did. Not that the Kate devs would be supposed to know that. Nor could we know that they would decide to use it either. IMHO, applications that are written as KParts should be somewhat restrictive when defining shortcuts and to the extent that it's sane and possible leave it up to the embedding app to set them. I don't pretend this is a complete solution either though. I don't know if it is kind of overkill, or even a good Idea from a Security/Stability standpoint, but wouldn't a kind of Hotkey "Registry" Mechanism help to deal with such situations? I think of a small lib inside Kdelibs, which handles all shortcuts (KHotkeys?). Any app (or KPart) would have to register the shortcuts it uses, so that clshes could be detected easily. Each App would then have a (or several) file(s) like "kdevelop.hotkeyrc" where every shortcut and its associated action is declared. That would help to make Hotkey-Themes, too. What do you think? kdevelop-3.1.91, KDE-3.3.1 (beta1), CVS 050113 [F7] is still used twice as described before, but kdevelop seems to catch it and does not relay it to the kate-part, so the active target is build, the command line is not affected. Don't know whether this is "fixed" in the ordinary sense ... ?! Please close in favour of bug #124384 |