Open Source

The responses to by previous blog entry were more then I hoped for. Among them was an invitation to join the KDE-NL BBQ, which was helt last weekend. Whooha!

As newcomer, the experience was mindblowing. Everyone has the same passion and because KDE has so much to offer, everyone has something different to tell about too. So there is a lot to talk about: the state of development, Akademy, KDE4, marketing idea's, plans that are going, and all kinds of interesting details. There were developers from Amarok, KOffice, Mailody, the Music Notation Flake (Soc), but also translation, and marketing/promo teams.

Everyone was genuinely interested in each others stories, everyone clearly showed respect for each other, and we had some good laughs. If that wasn't cool enough, consider how conversations went full speed. Where you normally have to slow down because you're talking too fast, there was nothing to worry about among KDE enthusiasts. It's said that people keep spending soo much time on KDE because of the community. I definitely believe that's true. I enjoyed every piece of that day, and love to be part of such events more often.

I went homeward with Jos Poortvliet and Niels van Mourik. We had a some difficulties finding the the highway because we spent too much time talking. I had some good conversations with Jos back home, and thanks to him I didn't have to make the entire journey back by train. This would have taken more then 2 hours in total, now only 20 minutes.

At the train station I had an interesting experience as well. I sat waiting there with my notebook bag and a Baguette left from the BBQ. Which is quite odd at 23:00 to say the least. Some guys joined me to ask if I was from France, where I got that Baguette from. Oh BBQ? where? with friends? Well.. how do you say this.. er.. have you heard about Linux? yes? .. I had a BBQ with guys who work on KDE in The Netherlands.... er.. a set of graphical programs for Linux! Oh Cool! You work on Linux? It was pretty awesome to talk with those guys at a train station about Linux vs Windows vs Mac OS (due to my notebook), and how that guy didn't like Windows but still used it. Not that we could talk in detail - time was short and it mostly went about stereotypes - but every bit helps.

I spent the evening talking over MSN till about 2am, and was well awake before the alarm went off too. What a day!

...someone else copies your layout and wordings. (compare: KMess version)

All I can say is: I'm flattered.

On a side note, I'm still looking for ways to improve the home page. I really like sites that show off their product well at the home page. The recent examples I found are:

• BasKet
• Firebug
• Mozilla
• Firefox features

Why is this important? With my application conversation I litterally got the question "what is KMess actually?". I never noticed it before; the home page simply didn't tell. It only rambled the news headlines of things that were improved.

I'd like to improve the homepage it visually as well, like the sites above managed to. The screenshot tour is a good start, but a bit too hidden yet. Every once in a while I'm thinking how to incorporate new ideas in our home page. Perhaps I manage to get something done with the 1.5 release. Contributions, designs and suggestions are welcome off course.

Image speaking to a new developer. With excitement you tell about the debugging features of KMess. We've got a network output window, and lots, really lots of console output. The console is literally flooded with messages when you run the debug-build of KMess. This allows us to trace how KMess interacted with the protocol messages, how it parsed those and sent responses back.

Now imagine this new developer doesn't see anything of it.

That's an annoying way to become challenged as developer. First you start guessing where the output could be. SuSE has a nice ~/.xsession-errors file that contains the output of all GUI applications. However, the messages also didn't appear either when KMess was started from a console window. Googling gave no insight either. It started to feel something is really different in Fedora Core.

My next stop was kdebugdialog. This is a tool that allows you to turn off debug output in KDE, separated by application and message type. I guessed the output was disabled there, which seamed logical from an end-user perspective. After some inspection, the settings were identical to my SuSE system.

KMess uses standard kdDebug() calls to output the messages, so I sent a little C++ file that did the most basic thing possible. Eliminating compiler flags, and #ifdef statements we use to hide output:

#include <kdebug.h>

int main()
{
  kdDebug() << "test output" << endl;
  return 0;
}

Again, this simple test application gave no output on STDERR or whatsoever.

I seriously started to fear KDE was patched by the developers of Fedora Core. This could mean the developer would never see the output. Stephan Binner has a site of distributor patches, for which I can't thank him enough. Browsing the folders I found a patch on kdelibs/kdebug. Compare the original file with this patch, and notice how Fedora Core hides all output by default! arhg! This not only costs one or two hours of debugging, but it's even more annoying it isn't mentioned anywhere. A simple note would have been enough.

The code of the original file acted as a good reference to find a solution. By creating the file ~/.kde/share/config/kdebugrc with the following contents, the new developer got his debugging output:

[0]
InfoOutput=2
ErrorOutput=2

This extends the global configuration in $KDEDIR/share/config/kdebugrc, and outputs all messages to STDERR.

Needless to say, I'll propably disfavour distributor patches even more then I already did (i.e. how a Wine developer wasted his Sunday afternoon on debugging packaging problems, scroll to "another example"). When something needs to be patched, it's likely the upsteam software lacks some option, not an other patch. In the case of KDE this wasn't needed at all, kdebugdialog is available already. Guess it's time to file some bugs, and hoping this post helps a bit too.

One of the things I really wanted to implement was a "Planet KMess" section at the KMess website. I've been looking for existing solutions, but couldn't find what I was looking for. I don't need expanding sections, or forum/e-mail like "mark as read" capabilities. Just a simple web page with all stories, posted in order.

As for why I'm not using Planet: the Planet KDE site is flooded with old feeds now and then. I don't want to see that happening for a "Planet KMess" website. Planet is written in Python and uses a file-based cache. This is a complete black box for me as Python illiterate, and adds Python as new dependency to the web site.

The result is a new Planet-like feed reader/aggregator named PhpPlanet. It is v0.1 software and can be downloaded here. It stores feeds in a MySQL database, and uses Snoopy/MagpieRSS to parse the feeds. Flooding is avoided by observing the timestamp of RSS entries. When multiple entries have the same timestamp it's an indication the feed is regenerated, and those entries will be rejected automatically.