apaku

KDevelop4 Release Candidate 1

Finally getting around to blog about this.

We’ve released RC1 of KDevelop4 today. We’ve fixed a couple of bugs and got some good performance improvements, but even more will be in RC2. RC2 will also ship with translations, for RC1 we’ve discovered a severe problem that we couldn’t fix anymore in time related to translations.

On behalf of Milian and Niko we’re also releasing the first release candidate of the PHP plugins, bringing great web development to kdevelop.

The tarballs can be found on all KDE mirrors.

Note that I had to update the php tarballs yesterday. I forgot to increase the kdevelop plugin version in their desktop files before uploading and hence they wouldn’t have been loaded with kdev4 rc1.

To make sure you’ve got the right ones the md5sums for those two are:
9aa5926ca68c618ee87603619547898b kdev-php-docs-rc1.tar.bz2
5e1e80f417afa958525ea682a309f764 kdev-php-rc1.tar.bz2

KDevelop4 Beta9 released

Yeah, finally, this marks the end of a rather long line of beta’s. The first one is more than a year old! But it also means we’re finally getting closer to a 4.0 release. Now its time to go through the open bugreports for KDevelop
and KDevPlatform.

Also make sure you read the dot story about the Hacksprint in Berlin with joint developer forces from Kate, KDevelop and Okteta.

Packages are available as usual on the KDE mirrors. Make sure to get the latest one as I had to do a silent update on sunday evening (forgot to increase the version numbers, really sorry), the md5sums are:
4b0b9bb343da46ead3ae9632a0bd9ce9 kdevelop-3.9.99.tar.bz2
180ee3573bd3d5ba805acc17d44fcbab kdevplatform-0.9.99.tar.bz2

Custom Buildsystem Support for KDevelop4

A bit of background first:

The buildsystem we (as in froglogic) use for Squish is custom written using Javascript and that means its not very nice to use KDevelop for hacking on the code. The reason is that KDevelop4 needs to know about includes and defines from the projects buildsystem to provide proper autocompletion and code-navigation.

Now the C++ support has some a small gui which allows you to store some custom include paths in a config file inside of the project. This works for small things, but Squish is buildable on various platforms and more importantly with different dependencies (Qt3 vs. Qt4, different script interpreters, tcl/tk etc.). So I have about a handful of build directories for various configurations and hence a single in-project config file for includes doesn’t work.

Initially I wanted to write a buildsystem plugin for our Javascript buildsystem, but that was simply too much work for me. So instead I’ve sat down (since january actually) and implemented a buildsystem plugin that is supposed to support any buildsystem out there by configuring the tools, includes and defines manually. Also the build directory can be configured, everything goes into a named buildsystem configuration which can be easily changed. So I can setup a separate config for each of my builddirs.

I guess now that you’ve read this, you’re eager to try it out, huh? The plugin is hosted on gitorious.org as I didn’t want to start it in svn, just to convert it to git in a few months. You can find checkout instructions on the page. If you find any bugs, you can keep them, or drop me a mail (I’ll consider using KDE bugzilla once the amount is large enough).

Even if there’s not much to see for such a plugin, I created a small snapshot of the configuration widget:

PS: I know that its currently not possible to delete entries from the project
paths, includes and defines. Working on that right now (who wants to delete there anyway??).

Writing unittests for KDevelop plugins

After just completing a basic unit-test for a KDevelop4 plugin I’m currently working on I realized that its really easy, but we lack some simple examples how to do this.

So I sat down and added an article to our Wiki that explains how a basic unittests for a KDevelop4 plugin is structured and how it works.

Its really important that setting up the necessary environment for unittests is easy, at least thats what my personal experience has taught me. If writing a unittest for a small bug one has found takes more than a couple of minutes because of tons of extra things to write (like having to implement certain interface classes with some dummy values, or setting up a complete gui first), then those unittests will never be written. The exception might be people being paid to write those, but this is seldomly the case in open source projects.

Hence its important to make it possible to add a new test for a feature or bug in as few lines as possible, concentrating only on the particular circuumstances that are required for the bug/feature. So with the above article and the framework KDevPlatform provides, there’s really no excuse anymore for not writing unit-tests for your plugins 🙂

KDevelop4 Beta8

I’m pleased to announce (as first as it seems) that KDevelop4 released its 8th Beta. This is mostly a bugfix release as we are slowly (but steadily) moving towards a final release. There’s going to be another Beta soon with (hopefully) some more features as the KDevelop/Kate Sprint just started.

Additionally to kdevelop+kdevplatform you’ll find Beta’s of various php-related plugins on the KDE mirros. These plugins enable language support (code-completion and navigation), php-documentation view and debugging of php code (both standalone and inside a browser via xdebug). These are provided by Milian Wolf and Niko Sams, so join #kdevelop and give them a hug for providing such outstanding php support 🙂

For those eager to try out (and when the distro hasn’t built packages yet), you can find the files on the KDE mirrors

KDevelop4 moved

As we decided that we won’t make the KDE 4.4 schedule and drop out of it, we thought that we should also play by the KDE policy rules and move out of trunk/KDE.

That move has just happened and KDevelop, KDevPlatform and Quanta can now be found under trunk/extragear/sdk/.

Everybody who’s running svn now needs to adjust his url using

svn switch svn://anonsvn.kde.org/home/kde/trunk/extragear/sdk/kdevelop

And similar for kdevplatform or quanta.

The tentative release date for KDevelop4 has been moved to end of march now.

Don’t install Ubuntu 9.10 if you want a stable KDevelop

First note: This is a bit of a rant, so be prepared 🙂

It seems that Ubuntu has reached another sad milestone on their way to the worst distribution ever.

Someone there thought its a cool idea to ship KDevelop4 Beta5 with a stable Ubuntu release.

What angers me most about this is that this not only hurts Ubuntu – I couldn’t care less about that – it hurts KDevelop and it also hurts me and other people trying to get KDevelop’s bugs under control. I’ve closed the 20th or so duplicate right now about a bug thats been in beta5 and has been fixed since weeks. Its a bug that’ll not be in the final release of KDevelop4, but its a bug I’ll probably get to see again and again in bugzilla for quite some time.

I never liked Ubuntu, but this really is a new level of broken packaging.

As final word something constructive: If you are running Ubuntu 9.10 either consider compiling kdevelop and kdevplatform from sources or report bugs you encounter with the Ubuntu kdevelop package to Ubuntu, not to KDE’s bugzilla even if thats what the Crash dialog suggests to you.

How to properly report bugs for KDevelop

Actually this probably applies to any FOSS app out there.

This morning I saw in my irc backlog (lucky you that I keep that and usually at least skim it):

[07:41:33] –> firefly2442_ () has joined #kdevelop
[07:42:29] <firefly2442_> I found a bug in kdevelop 3.5.3, in the project options under run options
[07:42:50] <firefly2442_> I can navigate and specify my main program executable
[07:43:08] <firefly2442_> however, when I try to run it, it doesn’t work because the folders have spaces in them
[07:43:46] <firefly2442_> the actual command that gets executed and run in the bottom window should be modified to add quotes to allow for folders with spaces
[07:43:53] <firefly2442_> should be a simple fix
[07:44:04] <firefly2442_> cheers 🙂
[07:44:16] <– firefly2442_ () has quit (Client Quit)

This is a good example of how you should _never_ try to report bugs or problems with KDevelop. Unless of course you just wanted to do a braindump which nobody cares. Its fine to approach us on IRC, but please don’t just dump things and then leave immediately.

The right way of doing this is by either using our bugreporting wizard at KDE Bugzilla or by at least sending a mail to one of our mailing lists so we can reply to you.

I know this is a bit more effort than joining into an irc channel and dropping a few lines, but really there are far better chances of your problem being solved doing the few extra steps.

Sadly this means the above irc-report will not go anywhere, I don’t even have kdevelop3 around anymore, so I cannot test this and file the bug myself. Not to mention that 3.5.3 is rather old (3.5.5 is current) and KDevelop3 is not actively maintained anymore.

KDevelop4 Beta5 tarball updated

Unfortunately I suck, hence the originally uploaded kdevelop4 beta5 tarball didn’t include the version increasement (thats the only missing change, so the help->about KDevelop will show the wrong version). I’ve fixed that now and re-uploaded a new tarball for kdevelop, this should show up on the mirrors in a couple of hours.

To make sure that everybody has the right packages, these are the md5sum for the proper packages:

70064ad0e285d29242a90af3f3c2283f kdevelop-3.9.95.tar.bz2
2ee0d124682bb3cbc3f1068389749e0c kdevplatform-0.9.95.tar.bz2


So if the md5sum of your kdevelop-tarball doesn’t match, re-download it in a few hours.

Update!!!!
It seems like screwing up once wasn’t enough this time, the kdevplatform package also had a wrong version. I’ve uploaded a new one, but syncing will again take some time. Here are the latest md5sums:

70064ad0e285d29242a90af3f3c2283f kdevelop-3.9.95.tar.bz2
e38fd54ea9c16b41222e893c06ca3946 kdevplatform-0.9.95.tar.bz2


KDevelop4 Beta5

I’ve just released the fith beta of KDevelop4 into the wild, so go get it 🙂

We’ve fixed quite some crashes and also implemented a few new features, among them improvements in the refactorings and a new patchreview toolview (see Views->Add Toolview). That allows you to easily review patches inline in the Kate editor. This way we combine diff-viewing with the powerful semantic highlighting from the C++ support.

I’d also like to point out that this is the last beta that will be working with KDE 4.2.x, the next one (still at least 4 weeks away) will need KDE 4.3.0 or 4.3.1 (we’re not yet 100% sure about the patch-level). The reason is quite simply that for 4.2.x compatibility we need quite some extra code/ugly ifdef’s and you’re missing out on some features which are only possible with 4.3.x.

Update: You can find the source packages on the KDE mirrors.