Some weeks ago, someone posted a question on the KDE PIM mailing list "Which IDE do you use" or so. This reminded me of the ideals of my youth when I believed that the better your IDE - the more efficient your programming work - the more you get done in a given time for your software development.

It is often said that many open-source-software is not enterprise-ready. But in order to be enterprise-ready, software must first be user-ready. I want to give you a feeling what I mean.

Today I fixed a bug that has been open for more than 4 years. This feels good. However, there is a reason why it took so long: kdialog contains a member winId() as you can see here, but this is not documented in our api documentation.

Writing good error messages for your programs is art. Your user gets an error message - he cannot ask his computer "how do you mean this?". Error messages are important because they can help you fix a problem. Some error messages are critical because the error prevents you from achieving anything. One example are the error message of startkde. When you have a problem with startkde, you have a real problem. If you cannot solve it, you cannot work (with KDE) at all.

As I pointed out recently, I only develop KDE in a virtual machine. It does not only enable me to rollback changes that screwed up something, it also allows me to go back to a verbatim snapshot where I can e.g. be sure that there are no mysterious plugins installed to directories that I have not thought of. I also pointed out that compiling in a virtual machine is slower, because you cannot use more than 2 processor cores per virtual machine. No problem!

When I heard that Nokia was giving away N810 devices on aKademy, I wondered how long it would take till I saw the first code changes. So, code changes to support the ARM architecture or the use of KDE on a PDA. Today I saw three (and wrote two of them):

• Require at least Strigi 0.6.0 (SVN trunk) because a BC change was needed in libstreamanalyzer to support ARM architecture.

Many of us know this: You are on KDE version "from yesterday" and suddenly, everything breaks. Maybe someone broke the kompile or it is just a bunch of bad code that went in before your checkout and prevents the window manager from starting.

You learn from this mistake, you no longer install to /usr, but you create a dedicated user for your KDE programming fun. Soon, the next painpoints arise:

• you cannot test the display manager
• you cannot test the latest system-wide dbus stuff

Since some years, I have searched for an elegant solution to generate call graphs out of C++ source code. Today I found it. It is doxygen. I have evaluated doxygen years ago, but I threw it away. The reason is that you have to know two things about doxygen:

• Do not call doxygen, start with doxywizard and everything goes straightforward.

I got kdesupport build in a maemo (scratchbox) environment and I documented every step in my beloved wiki. It is the first list item here.

Many of us have the cool Nokia N810 that is an ARM system based on maemo. To compile software for it, you will normally use scratchbox. What a pitty scratchbox only runs on 32bit hardware. As a proud user of a 64bit desktop, I have to use a virtual machine for running scratchbox. Now the question is what is the better virtualization solution: VirtualBox or VMWare?