Speaking of stupid mistakes and KDevelop3 bugs

February 28, 2008 at 7:14 pm | Posted in KDE, KDevelop, Real life | 2 Comments

What I really love about myself is that for some reason I can’t stop making really stupid mistakes. I know everybody makes them, but somehow I’ve got the feeling I’m doing much more than anybody else.

Latest two occurence are bugs in KDevelop3.5.0 (one of them being in probably all releases since 3.4.0). I mean how damn stupid does somebody have to be to

a) use 2 variables, one named line the other named sline in the same function and

b) then mix those two variables up, which results in this: Bugreport 158236

The other one was pointed out on IRC today, stupid logic mixup with the same code in the else-part as in the if-part of an if-else. No wonder that you can’t turn off the warnings in QMake projects in KDevelop3.

I only catched the last one “by accident”, because I usually read the IRC backlog when I wasn’t sitting at the PC for a while. This one probably wouldn’t have ended in bugzilla as apparently some people think its not worthwhile to file bugreports against KDevelop3.

Thats however not true, especially if you’re not using one of the unmaintained parts. But even then, no bugreport is always worse than a bugreport that gets closed as wontfix (or fixed in 4.0 which is not yet usable on a wide scale). Obviously the problem here is to know which parts are unmaintained. So here’s a (probably incomplete) list:

fortran, java, php, python (this one will come back for 4.1), sql, csharp, bash, pascal, kdevdesigner (short note: use the normal Qt designer, you loose almost nothing and gain a lot of stability), valgrind, fileselector (known to be pretty buggy), distribution packaging, texttools, clearcase, perforce.

I’m not saying that bugs (especially crashes and the like) against these components will simply rot, I’m just saying its unlikely that they’ll get much attention as we simply don’t have many active developers and need to work on KDevelop4.


  1. Hello,

    Is there a unit test for the Messages outputview.

    I assume KDevelop forks the child make process and then reads in the stdout and stderr which are produced.

    Therefore to test this, the make could be replaced with an invocation of a simple script which produces various messages on stdout and stderr.

    I often build systems with very noisy output. KDevelop is great with its “Very short compiler output” mode.

    Without this warnings got buried in thousands of lines of informational text. Therefore it’s a strong reason for people to use this IDE instead of the command line.

    Some time between KDevelop 3.5.0 and 3.5.1, the behaviour of “Very short compiler output” changed and it no longer condenses the output as efficiently as it did before (for my build at least).

    Since “very short” is a matter of opinion, do you have a set of rules against which this feature should operate?

    With a set of requirements we could then have tests to ensure we don’t get regressions from previous releases.

    If these exist already, could you point out where they are.

    I’d like to fix this so any help is appreciated. It’s also good to know that KDevelop3 is still open for fixes.


  2. No there’s no unit test. In fact KDevelop3 has no unit tests at all. (at least none that I’m aware of).

    IIRC we recently removed some of the filtering from the make output as it was getting really slow for lots of output. svn log on parts/outputviews/ should show you the commit.

    All the filtering logic is in that directory.

Sorry, the comment form is closed at this time.

Blog at WordPress.com.
Entries and comments feeds.

%d bloggers like this: