I've been pretty inactive in development recently for a few reasons (I got engaged, then I had a nasty fall from my road bike due to a tyre blowout). I was impressed by the great work that David Nolden continues to do for kdevelop, particularly the behind-the-scenes improvements which make using the program bearable. However as we know it's the new features which are the most 'bloggable'...

The new class wizard is currently pretty basic, but in a few hours I managed to link up the dialog with the definition-use chain, and the results are pretty impressive (for the amount of effort involved):

Here you can see a list of super classes which you're overriding, and the virtual functions which each class contains. The idea is then you can check those functions which you want to implement / override, and kdevelop will create the entry in the new class and the stub in the implementation file. This code is also mostly language-independent, although I need to speak to David about a few details there. BTW, it's not committed yet, pending a bit more polishing.

I started my first programming job on August 7th 1978 as a graduate trainee in the 'Advanced Systems Sector' of a company called Dataskil, and today is the 30th anniversary.

Another leap forward in KDevelop version 4 is the interface. We've tried to make it both highly flexible (to fit most people's requirements) and reliable (kdev3 suffered from a difficult to maintain ui library, prior to a simplified rewrite), and the current state is pretty good (certainly better than kdev3). Features include:

Features likely to be implemented at some stage include split toolview areas, and drag + drop of tool views.

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.

I'm currently at the KDevelop sprint at the Trolltech offices in Munich, Germany. We had a productive weekend of talks to bring everyone up to speed with the current state of KDevelop, and while what's going on under the hood is very exciting, it currently suffers from a kluged together, buggy and incomplete UI. For the first day of the programming several of us are working on improving the user interface, and it's making progress slowly but surely. Stay tuned for a screenshot / screencast when we have it looking just right

As part of the definition-use chain work that I have been doing for KDevelop, yesterday I wrote a browser for each document's chain. There was just one catch... none of the chain is protected for multithreaded access at the moment.

I'm pretty new to multithreaded programming, so I started with reading the Qt docs. Well, as those of you who have read it know, it is intended for programmers with a familiarity with the issues presented. Nevertheless, it did a fair job of explaining to me the issues.

This got me to where KDevelop is now - that is, it runs, shuts down, and can have its parse jobs interrupted without crashing. However, when I came to the definition-use chain, I knew it would take more than just what I could do with fine-grained mutexes to this point.

The difficulty with designing locking for this group of explicitly shared objects is that at first glance they can cross reference each other wherever they like, thanks to the #include directive. So, I was about to start on fine-grained locking inside each class across all classes. However, it just didn't feel right.

So, the reason I'm blogging now is because I've hopefully found a solution to this problem. In fact, when you look closer at the design of the chain, only certain objects create cross references - top level contexts, definitions which are separate to their declarations, and uses of definitions. Even better, the builders only need to acquire one of each type of lock at any one time, so hopefully this will avoid deadlocks too.

Thus, I'm planning to lock each of these three categories with separate per-object read/write locks. This even has the benefit that the second pass of the chain builder (the use pass) only has to write lock the use locks, and read lock the top context. Wish me luck...

PS: I was saddened to hear of the passing of Steve Irwin today, although he was a little overly Australian, he was unashamedly so...

In the recent KDevelop dot interview I noticed a very astute comment by someone named borker:

"One of the things I've loved about picking up Qt/KDE was how quickly you can make non-trivial applications, but I found learning Qt/KDE was a weird reverse... rather than writing code first and then learning the complexities of the build process later, as required, I found myself needing to come up to speed with the build process first and then write code. Not being overly familiar with the GNU tool chain didn't help speed up this process either. I found it to be a frustrating blocker to actually writing code and it wasn't helped by most of the available tutorials being great on coding advice but very slim on build advice, so when I wanted to go from 'hello world' to something a bit more 'real world' I ran smack into the build system and all my momentum died completely. Anything that could help a beginner like me out in the way of teach as you go type stuff would be great." -- link

I can't tell you how many times I've seen someone new to KDE/Qt development come into the #kdevelop channel after being absolutely floored by Autohell. Well, as you might have heard, KDE is going to be moving away from Autotools, so hopefully that will help. Here is a short introduction to all the build systems you might encounter in KDE land.

1. QMake Version 3 -- Used by Qt 3.x applications.
   Brain dead easy to learn.
   
   
2. QMake Version 4 -- Used by Qt 4.x applications.
   Brain dead easy to learn.
   
   
3. CMake -- Used by KDE 4.x and Qt 4.x applications.
   Fairly easy to learn, but more powerful.
   
   
4. Autotools -- Used by KDE 3.x applications.
   This will make your eyes bleed and your brain beg for mercy.
   
   
5. Scons -- Previously considered for KDE 4.x applications, but ultimately dropped for KDE/Qt development.

If you are a new developer and have no previous experience with KDE/Qt then learn #2 first. You need to learn how to use Qt 4 and this will be the most pain free way to do so. Once you've done that, then you can venture into KDE 4 land and learn how to use #3. It is not that hard and your experience with QMake 4 will probably help.

If you are familiar with Qt and how to use it, but you are thinking that you want to develop KDE 4 applications, then by all means start with #3.

Unless you are currently hacking on KDE 3 or have knowledge of Autotools, you have no reason to suffer through #4 especially if you are new to KDE/Qt development. Save your energy and learn QMake 4 first and then CMake.

If you like scons, great! But, please keep in mind that most KDE applications will be using CMake.

With the release of Trolltech's java bindings it kinda feels like Christmas. I wanted to point out some more presents under the tree...

Look closely at the dockwidgets on the right of the image. See that? Recent versions of Qt 4.2 snapshot include a new Ideal like feature. When you drag a dockwidget completely on top of another an Ideal like tabbed bar is created. This is done entirely within Qt and any application which uses QMainWindow will have this functionality. Pretty cool, eh?

This is a screenshot of KDevelop 4 as it currently stands. As you can see, we now natively integrate Qt 4 designer. You can thank Matt Rogers and Roberto Raggi for this one. KDevelop 4 is going through some pretty incredible changes right now. Hopefully the dot is going to host an interview with some updates on what is going on. Stay tuned!

KDevelop 4 screenshot with an integrated designer