This only works if the .h and .cpp files are on the same dir.  

Hmm, this is not a bug. This is the intended behaviour of kdevelop; and it is not planned on implementing it.

Since, there is no way, that we could know how to map a source file in /src to a header in /include? This kind of project is actually very seldom.

Making it a wish and closing as WONTFIX.

I have a similar project at work with separate header and
source directories. And I'd like to have a working
switch-command, too.

Hi, 

sorry for reopening the discussion. As i suggested  here:

http://bugs.kde.org/show_bug.cgi?id=79406#c3

it should be posible to implement a feature like this when the new classparser is ready. 
bye fox

I am working also with custom projects where might happen that some headers are not placed in same directory than source code implementation is. Not so rare. For those files, this functionality is not working. 

If kdevelop does not find header/source to switch because not placed in same directory, should find all project files which match FileName (all FileName.h or all FileName.cpp). If more than one just open a dialog and let the user to pick one of them.

I propose the attached patch as a fix for 3.4. I will post the patch to the mailing list for applying.

Regards,
        Florian Hackenberger

Created attachment 14832 [details]
This patch looks for matching files within all files in the project.

Could someone please check if using iterating (pluginIt) over
QValueList<KDevPlugin*> pluginList = pluginController()->loadedPlugins(); and
then checking all files in the list obtained with fileList = (*pluginIt)
->codeModel() ->fileList();?

...is ok (forgot to type that *gg*)?

No.. I don't think that patch makes sense. I can see no reason to check the codemodel more than once, and you don't need to jump through hoops to find it to begin with. 

Furthermore, the codemodel works on the project files, and you can get the list of project files simply through KDevProject::allFiles().

Seeing how you're already in the plugin part class, all you need is:
QStringList files = project()->allFiles();

Once you have a few files that look like possible candidates, you can try to find out if one of them is a likelier match than another.

Thank you for pointing out that iterating over all plugins is uneccessary. Attached you can find a second try. I'm not sure if I really get your point, but as far as I see the case, this bug is about finding header/source files in another directory as the directory where the source/header code is located. Although I agree that it would be nice to choose the best header/source files if several options are available, the patch solves the bug. But we should file another bug (wish) for the feature you mention. Could you (Jens) please have another look at the patch? Thanks, Flo

Created attachment 15422 [details]
Improved patch

Yeah, that looks much better to me.

I'd avoid running QStringList::split( ',', possibleExts ) over and over, that's a list you know will not change. I'd also avoid going through the projectFiles at all until you know that the naive check-this-directory has in fact failed to produce a hit.

Assume that the list of project files *could* be 5000+ files. You don't want to hang the UI for several seconds if you manage to hit "switch" when in a file that has no corresponding header/source file, forcing you to traverse the entire project file list.

I should have spent 10 seconds more on actually looking at my code before posting it. Find the improved patch attached and thank again for looking at it!

Created attachment 15426 [details]
Even more improved patch

Looks nice. I'll try to test it later tonight. I'll commit it if it works. :)

Committed as 526869. Thanks for the patch! :)

You'r welcome!