KDevelop 4: A New Era

I've decided to write a series of blogs detailing the work that has gone on behind the scenes for KDevelop version 4, the new IDE that is now 3 years in the making. Like KDE4, KDevelop has seen much work on essential internal mechanisms (much like the pillars of KDE), the power of which will become evident over the next year or so. Progress has been great recently, with the hackathon we had in Munich earlier this year, productive SoC projects and several more/new developers becoming active again, it's looking like we can expect to be releasing a pretty solid beta within about a month. The other developers and I use kdevelop daily to work on kdevelop 4, including writing code; version control; building, executing, debugging, and valgrinding programs; navigating the project with quick open, find in files (grep), etc.

In today's blog I'll concentrate on language support, arguably the most important feature of an IDE. I've previously blogged about the underpinnings of the new language support, which is arguably the most important cornerstone of the technology developed for this release. It consists of an extensive definition-use chain and type system; this means that KDevelop knows accurately where all of your declarations, definitions, types etc. occur, and when you use each of them. Comprehensive code completion, refactoring and other advanced tools will all flow on from this.

Two things have struck me about the definition-use chain (duchain) work recently. Firsty, our code has matured and is working well. When I was last blogging (too long ago, I know), I wrote about how it was difficult to make it all work with multithreading, and that c++ support was incomplete. Now I have learned much more about threading and locking issues, and the scheme that I finally settled on (one global read/write lock for the entire duchain) has solved the problems. This is important not only so that KDev4 can make use of dual/quad core machines, but also so that background parsing occurs without getting in the way of the user. C++ support has matured over the last year (thanks to David Nolden) to include full macro and template support (which are not easy tasks, the complexity of tracking macros accurately throughout include files caused many headaches).

The second is that we've started generalising what code we can to share between different language supports. It now takes very little effort to implement a duchain for a new language, once you have a parser in place. Java, C#, and PHP have all made encouraging starts (python too, but that effort is currently unmaintained), and I've found that the effort required to develop a duchain for a language is much less because of the shared code. All have relatively complete duchains within each file, and the c# duchain took only a few hours for me to implement. I've put some quality time into developer documentation as well, which can be found on api.kde.org. Once a language has a working duchain, it's ready to share in the features which were created initially for c++, such as code model, context browsing, and code completion [already implemented] and the sure to follow refactoring support. If you want to see your favourite language well supported by kdevelop 4, we'd appreciate your help - other than c++ and php, there are no major active maintainers. I believe C# and Java are especially important secondary languages for kdevelop to support.

DUChain performance and reliability has been the focus of David and I for the last few months, especially given David's SoC project on "Rock Solid C++ Support". Memory usage has been dramatically improved, and many bugs have been tracked down, especially with regards to text editor integration. The next step is saving everything to disk ("persistance"), because although the parsing is pretty efficient, enabling complete on the fly duchain support for a project is like trying to compile the project and all of its dependencies every time it is opened otherwise. Once we have duchain persistance, the navigation features already implemented will become much more useful.

If you want to get started using kdevelop now, checkout and compile kdevplatform and kdevelop modules from svn. Bugzilla is open, and we would especially appreciate* any reports of incorrectly parsed c++ code (you'll notice red highlighting, and the problem reporter will detail any errors (*with the exception of the known bug highlighting the first character of a document)) or crashes.