I’m happy to announce the immediate availability of KDevelop 4.2 RC1. This is a pure bug fix release over the last beta in the 4.2 branch. Anyone using the 4.2 branch is urged to upgrade to this new version as soon as possible. Furthermore any new testers are welcome and feedback appreciated. Report it on the bugtracker on bugs.kde.org. Keep in mind that if you are using KDE 4.6 or higher, you need this release, as 4.1 only works up to KDE 4.5. If all goes according to plan, there will be another RC soon and a final release together with KDE 4.6.

* David Nolden: backport from master: Clear the file-modification cache instantly when the user has saved the file in the editor.

* David Nolden: backport from master: Don't completely ignore the retrieved top-context if it is still flagged to require an update. Instead, simply show a warning message on the status bar. (TODO: Find out why the update flag is not correct)

* David Nolden: backport from master: Exclude the "." when extracting the extension

I’m happy to announce the immediate availability of KDevelop 4.1.2, a pure bug fix release without new features. Anyone using the 4.1 branch is urged to upgrade to this new version as soon as possible. Keep in mind that if you are using KDE 4.6 or higher, you need the 4.2 branch. This release works fine with KDE 4.4 or 4.5 though.

Note: This is - probably - the last release in this branch. We are now concentrating on 4.2 and what will become 4.3 eventually.

I’m happy to announce the immediate availability of KDevelop 4.2 Beta 2. This is a bugfix release over the first beta release two weeks ago. Every tester is urged to update, any updated feedback and bug reports are highly appreciated.

* Dmitry Risenberg: Check for unloaded version control plugin in ProjectPrivate.

* Dmitry Risenberg: Check for unloaded version control plugin in ProjectPrivate.

* Milian Wolff: reintroduce the cleanup of 986ec7bb18211a7789e28c48fdc750668ae9b1d5 (no addViewSilently, no window->setArea in working set loadToArea), but fix the problem described in 2f586e506ac59153b0b95e008acc88cea490e7d3 (restoring of split views)

I’m happy to announce the immediate availability of KDevelop 4.2 Beta 1. This is a testing version and any kind of feedback would be welcome and appreciated. Please use our bugtracker. You can download the sources or wait for your distribution to create packages.

Note: Anyone who runs KDE 4.6 or later needs this version (or any later). This is because the SmartRange interface in Kate got nuked and replaced with MovingRange interface. Many thanks to David Nolden for more or less single handedly porting KDevelop to this new architecture.

The good news doesn’t end here though, KDevelop 4.2 ships with lots of notable changes and new features:

Along with these big changes, lots of small improvements have been made and we will continue to polish and harden out this branch in order to give you a stable, fast KDevelop 4.2 soon. Considering the impact and amount of changes, testing would be very welcome in order to prevent regressions and similar in the final 4.2 version.

Bye and thanks again to all contributors who made this possible. I’m especially thrilled to welcome so many new people, well done!

If you run this through callgrind, you’ll see quite some time being spent in l.size(), the compiler doesn’t seem to optimize that away. Now, fixing this “bottleneck” is simple, look at version 2. That way, l.size() will only be called once and you’ll save quite some instructions according to callgrind.

Now, my first impression was: Yes, lets fix this! On the other hand, this optimization is not really that noticable in terms of user-experience. So my question is: Is it worth it? Should everything one sees in callgrind that is easily avoidable and optimizable (like the stuff above) be optimized?

I ask because QTextEngine e.g. doesn’t use the optimized version and I wonder whether I should create a merge request for that. According to callgrind the difference is noticeable: One of my testcases shows ~8% of the time being spent in QVector<QScriptItem>::size() (via QTextEngine::setBoundary()). In Kate the difference is even bigger with ~16% of the time being spent in QList<QTextLayout:.FormatRange>::size() via QTextEngine::format(). Hence I’d say: yes, lets optimize that. I just wonder whether it’s noticeably in the end.

just a quick note: The second google code-in task for KDevelop got completed, this time by Furkan Üzümcü. He shows off some features in KDevelop 4 that together make up the advanced C++ support you can find in it. Take a look at it:

Woha, back when Lydia announced Google Code In and asked me whether I’d like to mentor some KDevelop projects, I wasn’t so sure this was a good thing. But then I saw that documentation could be requested from the students, and well… KDevelop 4 has no real documentation (except this) - why shouldn’t I try it?

So I put a few “screencast workflow XYZ” tasks into Google’s Melange Web Interface (which btw. sucks so much it’s incredible) and forgot about it. I didn’t really think there would be school students being interested in KDevelop, esp. not in writing documentation or doing a screencast. But thankfully I was proven wrong, and in all levels. Please behold, the first documentation screencast for KDevelop, showing you how to get started with a project, setting up a launch configuration, and doing some basic debugging:

I’m amazed by the quality of that video, very well done Geoffry and thanks already to Google for the Code In. Lets hope more students will provide me with such good work :) And I hope this helps some users to get started with KDevelop 4.

PS: KDevelop 4.1.1 will be anounced tomorrow, replace functionality was merged for the “Find in Files” plugin and development is actively continuing :)

another blog post today, I’m on fire :) This one is shorter though: I want to notify you all that Quanta compiles against KDevelop master again (i.e. what will become 4.2 and uses the MovingInterface from Kate).

If you are using KDevelop 4.1 and want to use one of the Quanta plugins, like XML or CSS language support or XDebug or Crossfire integration, checkout the 4.1 branch.

I hope to work more on Quanta again over the next days, hope I can finally get it into a usable state…