apaku

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.

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.

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.

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


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.

I’ve just finished a rework of the GUI to configure launches. This is mostly based on feedback I gathered via bugreports, irc chats and mailinglists. Apparently a combobox to just add/remove tabs to an existing tabwidget isn’t working well and suggests to users a completely different thing to configure. Also people expected the selected combobox value (i.e. the launch mode) to be saved across invocations of the dialog.

So this was just confusing people that didn’t write the gui themselves and lead to me explaining how things work over and over again. With recent svn (and this will be in the next beta too) you’ll now get a bit different view:

As you can see for each launch mode supported by a launch configuration there’s a separate subitem under it to configure the specific things for that launch mode. This of course depends on the actual launcher used for the mode (i.e. which debugger is used for the Debug mode). The generic pages for a launch configuration are available from the launch-config item itself. In the example shot above you can see this includes the actual application to execute, configuration of the dependencies and so on. These settings are used by all the launch modes.

Feedback would be appreciated, preferably via our mailinglist or bugs.kde.org, but if you’re too lazy just add a comment

We’ve just released the 4th Beta of KDevelop4 and its coming along quite nicely.

This one even compiles on Windows (using MSVC9 aka MS VS 2008) and also is able to load projects. I haven’t been able to try out more things, like file-parsing or code-completion. One thing that won’t work for example for sure is building any cmake project as we don’t yet have any support for nmake.

So the Windows port is not ready for public consumption (as opposed to Beta4 on linux) but it does make progress again.

These are short and (hopefully) precise instructions what you need to do when you’ve built KDevelop4 from source and installed it somewhere other than your KDE libraries are (those are often from packages and then installed in /usr or /opt/kde).

I’m assuming here that you have the KDE libraries installed in /usr (i.e. from some packages) and that you’ve installed KDevelop4 into $HOME/kdevelop4 (by passing -DCMAKE_INSTALL_PREFIX=$HOME/kdevelop4 to cmake). If your paths are different just substitute them. Also I’m assuming you’re running KDevelop4 from a terminal and not via the run dialog or via a menu entry, if you want that to work you need to find out how to set environment for the whole X11 session – thats usually distro-specific.

So, first thing to do is setup the KDEDIRS magic environment variable. It tells KDE core components where to search for plugins and other data related to KDE apps and contains just a list of paths (aka prefixes) where KDE libraries and/or applications have been installed.

In my example I set KDEDIRS to point to /usr and $HOME/kdevelop4 as those are the two places where I have KDE4 apps:

export KDEDIRS=$HOME/kdevelop4:/usr


Next thing is to run a KDE tool called “kbuildsycoca4″, this reads various config files that describe which plugins are available and builds a cache from that information. This is necessary so KDevelop can find all its plugins.

And last but not least you can simply run KDevelop by typing “kdevelop” and hitting Enter.

Anybody who reads the dot will already know, but for those who don’t (yes I mean you): KDevelop4 has released its third beta. We’ve fixed tons of bugs, added a new launch framework, new C++ features and added a whole new way of switching the perspective from code to debug and back (KDE4.3 only).

However since the tagging on the weekend a week ago, David somehow has gone crazy on fixing all kinds of mysterious (well to me at least) crashes and locks, as well as some speed improvements. Additionally Thomas McGuire – a KDevelop fan and PIMster – sat down, digged in our complex ui-library and fixed one of the most annoying bugs ever found in this still new codebase: https://bugs.kde.org/show_bug.cgi?id=170863 (the one that resizes the mainwindow even in maximized mode when opening the find-bar from kate).

Hence we’ll shortly be releasing another beta (hopefully with some more fixes/improvements for valgrind, the debugger, launch framework and a new progresswidget). I don’t have any date yet as it depends on some administration stuff to be setup first, but you’ll notice when it happens