Hi planet! I’ve been registered a long time ago, but sadly this is my first post here. I’ve been too busy with getting “real” stuff done on KDevelop.
One short statement about Qt Creator: Imo they seem to have nearly the same goals KDevelop4 has: Modularized, platform-independent, light-weight, C++ oriented, with good Qt support.. why do they have to re-invent everything? I would have preferred them putting some resources into KDevelop4 instead. One thing is for sure: Their app may be stable, but feature-wise they are far behind, although I am biased to see this mainly from a C++ support perspective.
But now to KDevelop:
In KDevelop4, we have a language-independent structure for abstract code-representation called Definition-Use-Chain, that has been invented by Hamish Rodda a few years ago. When I started hacking on it soon 2 years ago for my Google Summer of Code project, he had stopped hacking on it for quite some time, and it was in a state you can call “experimental” at best. Nearly 2 years of hacking have passed, which were really hard years of instability, without the target visible on the horizon, without even knowing whether this stuff I’m working on even just “can” work out. Hamish came back about a year ago, and since then has been a pushing force on KDevelop4 again, also helping me with the kate problems that I really didn’t have any insight to. Anyway it was a monster-task. I often had to work on 3 places at the same time: kate, kdevplatform(duchain), and kdevelop(C++ support), all with tons of code that was until then exclusively used by KDevelop’s until then unfunctional C++ support, which means that lots of this code was unfinished and unstable.
The good news: All the pain is starting to pay off. 🙂 This April we had our Developer meeting in Munich, and since then the development has heated up, and I think we’re on track to get a stable release out within the next half year.
I have very high demands in the C++ support, and now they are starting to be satisfied. KDevelop4 has reached a state now, that I actually finally can suggest interested people to try it out. It’s important that you have recent kdelibs + kdevplatform + kdevelop, because all of them have seen some quite important changes in this area in the last weeks.
Since we got new competition from a direction from where I actually would have expected support instead, I feel motivated now to present you some of the nice features KDevelop4 has, so we don’t lose too much of the public interest.
The last days I have worked hard on finishing the basics for refactoring and use-searching, aka “find all calls of this function”, and got that ready. I’ve put it into a re-usable base-class, so functionalities that need this backward-searching are very easy to implement now. What mainly comes into mind is intelligent renaming/refactoring and call-graphs, which is just a matter of writing a user-interface for it with this in place.
Also I’ve continued polishing the widget to show this information.
Here you’ve got a nice screenshot:
At the top you see the editor-window, and at the bottom the code-browser which currently shows the uses of KDevelop::DUContext. The buttons are used to expand/unexpand the uses in the file. Then each file is split up into “Contexts”, which are functions or class-declarations. This allows you to get a fast overview in what place the use occurs. A tooltip over the line shows also the surrounding lines of eeach use, and clicking on the link on the left side jumps to the use directly in the editor window.
Next time I’m going to present you another nice feature of KDevelop4. 🙂