apaku

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

Hi,

just connected a usb drive here to check whats on it, as KDE4 is so nice to show a small popup allowing me to directly open a file manager on the mounted disk I took the option. Turned out there is only 1 tar file on it. So I clicked on it and was presented with the nice “no app found for the mimetype, please select on”. After a quick run through the tree nothing showed up that would open tar files. Ok this machine has a rather limited kde4 installed (due to size constraints) so I quickly checked the trunk/KDE modules for possible archiving utilities. Found ark in kdeutils, but after building kdeutils it only presents me with rar and various zip formats.

Is this right? Don’t we have a single utility in trunk/KDE that can open up a tar archive? Or am I just blind? Can’t be that hard to use KTar from kdelibs, can it?

Well, back to my own world of a shell and the always-there “tar” utility Oh and off to filing a bugreport against ark of course

C++ support in KDev4 really rocks, if kdevelop doesn’t crash. Unfortunately it did so about 6 or 8 times in the last hour, luckily most of the time it was the second instance in which I tested my changes The main instance was only crashing when I removed the .kdevduchain from under it, to get the second instance up and running. Apparently the repository management needs a bit more safety..

Anyway, what I wanted to say is that C++ support rocks. David already blogged about the various things he did, but today was the first time since a long while that I actually used KDev4 for more than 5 minutes (well, just about 2 hours, but still). It actually saved me a handful of compile-fix cycles in that time, which I find quite valuable, especially as I get easily frustrated when there are spelling mistakes or some stupidity created by me. Obviously it doesn’t catch all problems, but if I imagine I compile my code at work only twice instead of 5 times to get a fix into it, that would already save quite some time over the day.

On other news: I’ve implemented a (currently rather simple) selection controller on the weekend and now I’ve added some code that uses it. This makes all the build-related actions in the project menu enable/disable themselves properly. And more importantly it allows to simply build the selected item(s) from the project tree. Nobody needs to figure out anymore how to use that buildset thing (which will stay as its quite usable when building multiple things).

The next step I want to do is making the initial usage of CMake projects easier by adding configure() as a dependency to build(). And then configure() will check for a builddir and if none is configured it will ask for one. This would mean that after creating a new cmake project or opening an existing one you can simply hit “build” and kdevelop will ask you for a builddir and start building afterwards. Hopefully I get that done over the weekend.

Oh and before I forget it, I revamped (yes again) the Project->Open, now its again a “plain” file selection dialog. However it now allows to select a .kdev4 file or any file that can be handled by one of the project plugins as “project file” (i.e. cmake plugin support CMakeLists.txt, QMake support .pro files and Makefile plugin supports various types of Makefiles). Along with support for opening a directory directly with just the generic importer. So I managed to integrate import+open into one dialog without any drawbacks (at least I can’t see any).

No pics, its 12am and I need my beauty sleep right now, if you want to see it: fetch kdevplatform+kdevelop from svn (and kdelibs rc1 as you’ll need that). Unfortunately nothing of the above is in the last released alpha from those modules.