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'...

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:

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.

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 :)

I've made it to my second lot of annual leave this year, so I've bought a nice shiny new digital SLR (the Sony a100) and am going to Japan for two weeks for a holiday.

If there are any KDE devs or users who'd like to meet up in Japan (and preferably can speak english, as my japanese is non-existant) drop me a line...

So, the last two days I've been concentrating on introducing locking into the definition-use chain which I've been writing for KDevelop. I've taken quite a coarse-grained approach, with one lock for each document's chain, and with separate object local locks each time that an object can reference another object that is on a different chain.

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.

Firstly, thanks to clee for adding me to the Planet. When I left Trysil I planned to blog more often, and now you too can read about it :)

So, for the last 2 weeks I've been on annual leave, and have had the fortune to be "on a roll" with my coding. I'm currently concentrating on KDevelop 4. We're privileged to have a new parser framework by Roberto Raggi and Jakob Petsovits. I've been working on extending this good work with a new type system and definition-use chain.

Yesterday I did some more work on KDevelop's c++ parser, specificially the definition-use chain (duchain). This was in response to some bugs that were being revealled by using it as the basis of advanced code highlighting.

For those of you who might not be aware, KDevelop v4 is starting to take shape, at least behind the scenes. For some time now we have had Roberto's new c++ parser in the code base but not doing very much. Then Matt and Adam worked hard on improving project management support (including native support for CMake) and the background parser / code model, so now we have a functional code model (even if not in the final state).