Version: 3.0.90-CVS (using KDE 3.2.90 (CVS >= 20040117), compiled sources) Compiler: gcc version 3.3.3 20040125 (prerelease) (Debian) OS: Linux (i686) release 2.4.23-1-k7 (copying from another bug report--this is not a duplicate though!) The F9 key is currently assigned to: View -> Show Folding Markers and Build -> Execute Program is still a bug in case you use PHP. For my C++ project the above bug is gone, but for PHP it is definitely there. Thanks a lot btw for the PHP mode it makes learning the language a lot easier :-)
There isn't a whole lot we can do about that except trying to keep track of every kpart that could possibly be loaded into KDevelop and try to avoid using the same shortcuts. This is clearly not realistic. In this case, it's a little more embarrassing, since we're talking about the most commonly used editor part. However, IMHO, the problem here is katepart's frivolous use of the function keys. I mean folding markers, c'mon! For me, this is a WONTFIX. Dunno about anyone else...?
On Saturday 28 February 2004 02:03, Jens Dagerbo wrote: > There isn't a whole lot we can do about that except trying to keep > track of every kpart that could possibly be loaded into KDevelop and try to > avoid using the same shortcuts. This is clearly not realistic. I agree. At least doing this by hand is surely not an option. Wouldn't it be possible to enhance the infrastructure in a way that this is done semi-automatically. I don't know kparts well enough, therefore the following might not be doable. The one who writes the kpart, e.g. kwrite in this case, probably uses something like KAction / KShortcut. These shortcuts should be stored in a list. Now the same is done on the kdevelop side. When the kwrite part is loaded the shortcuts get merged and are reassigned in order to avoid collisions. That means that there should be a list of alternative shortcuts in case one shortcut is used twice. If no alternative is possible than one action wouldn't get a shortcut. Even better would be giving each shortcut a priority number. This would guarantee that very important shortcuts such as "F9"="run" can't be overwritten by a low priority shortcut like "show folding markers". As I said I don't know the infrastructure well enough if something like this is doable, so perhaps this is just dreaming. > In this case, it's a little more embarrassing, since we're talking about > the most commonly used editor part. However, IMHO, the problem here is > katepart's frivolous use of the function keys. I mean folding markers, > c'mon! > > For me, this is a WONTFIX. Dunno about anyone else...? It's a bug and I am sure that it is possible to solve it somehow, therefore I wouldn't tag it as WONTFIX. But it's probably something which can't be solved on the level of kdevelop--perhaps it's better to reassign this bug to kdelibs? At least this kind of shortcut collision will happen more often in the future if kparts are used for even more things.
OK.. we can keep this one open forever, but we won't fix it, so closing as WONTFIX seems more "honest". Yes, you have a point about reassigning to kdelibs, but I can't see it fixed there either. I think this is simply an unfortunate issue inherent in the part embedding design. If the shortcut set were to dynamically adjust depending on the active embedded part, they would be quite useless as it would be more work finding out what the current shortcut was than to use the action through a menu. IMHO, the most reasonable solutions seems to be to let the user decide and manually adjust the shortcuts to his/her needs. Sadly, WONTFIX. :(
O.k. thanks for taking the time to comment on it.
Hi, I know this has been commented on before, but the same problem exists with F7 in the C++ IDE (at least). F7 maps to "build active target" and also "open command-line". This is quite annoying, and means that KDevelop doesn't do what's advertisied in the tooltip. I know you've said that the F9 problem is a WONTFIX, but to me this is quite key functionality. Thanks.
Uhm, its the same problem, "open command-line" (or Switch to Command Line as its called in english) is also something that is provided by kate so we can't do anything about this. But how about changing the shortcut for one of the two actions?
Yeah, of course that is an option. :-) It is just (trivially) annoying, and doesn't really look that professional. Anyway, thought I'd put the problem on record. Pete.
Well, rest assured that you're not the only one that is annoyed by conflicting shortcuts and other weird things happening because our xmlgui stuff isn't all that well-thought-through. Luckily a replacement will be made for KDE4, so there's at least hope that KDE4 will look more professional in this regard. However every app that allows to load plugins and allows those plugins to change the menu - including defining shortcuts has this problem, you just can't avoid conflicts when you don't have control over all code.