KDE Blogs 

OSNews has a poll and discussion about integrating Mono into Gnome. As KDE may face a similar decision at some point in the future - what to do when KDE's technology is not competitive anymore - I thought i write my thoughts down in my blog instead of the OSNews forum. In the last weeks I have spent a lot of time on taking a close look on .Net and Longhorn, and I think it is quite nice. Certainly not perfect, and there are many things that I would have done differently, but it seems to contain less brain damage than Java. They certainly took a good look at Java and fixed its problems and shortcoming while designing C# and the .Net APIs. Assuming that the Mono guys can complete the .Net clone and its GTK integration and get it stable, Mono+Gnome would be a development platform that's much more powerful than the current Gnome, and for applications that can make use of the .Net platform's advanced features (like their XML, SQL and Remoting support) also better than today's KDE. Mono will be also able to make use of libraries, both free and propritary, that have been written for Microsoft's platform. Developers who are used to .Net will feel home on Gnome. And books written for .Net will also help Gnome developers. I still think that it is a bad idea. Why? A cloned framework puts innovation in Microsoft's hand. You still have the chance to write better applications, but the innovation of the platform will always trail behind. What advantage does free software have when its innovation is limited to that of its competition? Sure, cloning gives developers a common goal, similar to Linux's original goal of cloning a Unix-kernel. And Linux has been very successful in replacing Unix. But the .Net situation is different. Unlike Unix, Windows and .Net are under active development. Microsoft recently announced massive improvements to .Net, and it is likely that this will continue. Linux has two advantages over Unix: it is free and it is better. Mono will just be a free clone that trails at least a year behind. And that will also be the public perception, Mono will look like a cheap imitation and not the real thing. Even if the original may be so good that an imitation is still nice, it's like saying "Hey, we aren't capable to produce something better than Microsoft, so just clone their work". For some people this may be fine, but it is certainly not a plan for world domination. Mono could, of course, try to add additional APIs to .Net. GTK# is an example for this, since it is a replacement for Winforms and certainly better than the original in many ways. But as these new components are also free software (assuming they are under LGPL or BSD, like Mono) all improvements to Mono will also be available for the proprietary .Net. So by adding new components you can't make Mono better than .Net, you will always improve both. Maybe it comes down to the question: why are you working on free software? If you only do it because hacking some code is fun, the Mono solution is ok for you. If you do it because you want to create a free alternative to proprietary software, Mono is a fine solution as well. But I do it because I want to create better software. Hopefully so much better that in the future the world's information flow is not solely controlled by companies whose main interest is increasing shareholder value. Being free is an important aspect for software, but being technically better is not less important for archieving this goal. And Mono is no solution for that. Read More

What if, instead of basing our platforms, software and development paradigms upon chasing what we perceive the competition has today, we based our decisions upon user demand. So when a group of people actualy need something, someone (probably people invovled that group having the need) make it. If nobody needs feature/library/component/technology X, nobody makes it and the platform isn't weighed down by it. If this sounds a lot like how things work in open source, it is. Read More

Yes i have implemented it in Kompare and committed it to CVS but unfortunately it is not activated atm. It is not open for discussion before people start begging me about activating it because it is not in the release plan and it is way too late for new features. Read More

I was out having a pint with a fellow when he mentioned he uses (and quite likes) Evolution as his email client. He had a few gripes about it, but then don't we all when it comes to the software we use day-in and day-out? He then mentioned how he was surprised at just how huge a program it was. i asked if he knew how many lines of code went into Evolution, and he guess about right. I then asked him if he could guess how much had gone into Kontact; he though a little less than Evolution, but probably a similar amount. This is, however, far from the truth. Kontact is dramatically smaller that Evolution in terms of code count, even when taking into consideration all the various apps that are associated with it (KMail, KOrganizer, KAddressbook, libkabc, the various kioslaves). Then he asked a very interesting question: if I wanted to make a KDE mail app that was an alternative to KMail, would I be able to, would the KDE project encourage such an effort, and how much work would it be? Read More

Here's a nice piccy of a water colour effect that was created using Javascript. It was originally one of the n7y pics - enjoy!

I'm going to try something different. (insert knowing laughter here) it seems the topic of "Why KDE" is coming up more and more often in my day-to-day life both on- and off-line. sometimes the actual topic is "Why open source" but i usually manage to steer it into "Why KDE" because KDE is something i'm rather interested in and it provides a great case study. through these conversations i've come across some interesting thoughts, and i'm going to record them here over the next little while, one per blog entry. here's #1. Read More

Some time before KDE 3.0 David Jarvie, the author of KAlarm, asked me some questions about the KOrganizer alarm daemon. I answered that it would be a great thing, if KOrganizer and KAlarm could share the same daemon, because I thought that by eliminating redundancies development would become easier and we could use our development resources more efficient. So we imported KAlarm into the KDE CVS and David did a great job implementing the code needed for sharing the daemon. The result was that we had a new application and the shared daemon in KDE 3.0. So far so good... Read More

Now that the first dust about the first beta is settled, my thinking of how to continue gets more and more in foreground. Bug fixing continues at a nice rate, but there are still some show stopper bugs that were fine for beta1, but are not for whatever comes after: flash content missing (bug:65868 ) quite some khtml regressions, that show up on quite some pages (e.g. bug:66490, there are others) kwin hides cookie windows (and korganizer even windows) because of focus stealing prevention These bugs _have_ to be fixed, there is no way around it. But in general there are of course the two golden rules of releases: you'll never get it right whatever you fix, it might break other things (it might be they have downsides originally - I forgot then :) Anyway, I think if just the right ten bugs are fixed, we could release tomorrow. If - in reality we might end up with another beta before christmas and the final somewhere in june ;(

So, finally KOrganizer's bug count got down from almost 95 bugs in July/August to 44 right now. The last few weeks I was really busy producing patches at quite a rate. But every time I tested a patch, I ran into the next bug, and then the next, and so on. But I think, korganizer is really getting into shape now for the KDE 3.2 release. As far as I'm concerned, all the important issues are resolved / fixed (I don't know about Cornelius, and he's the maintainer of korganizer, so this list is only "unofficial"): The resource calendar replaced the file based system korganizer had in previous releases, so each user now has his very own system-wide calendar consisting of parts from several sources (birthdays, files, shared network calendars etc). I really think this resource framework is one of the best things that could happen to kdepim... Whoever is responsible for this (Cornelius?) really deserves an award and a spot in KDE's hall of fame! Alarm daemon works again with the resource calendar (due to Cornelius' work) KOrganizer's printing system got a lot more options than it used to, and it was factored into separate classes, so KDE 3.3 will get a print plugin system. Then it will be able to easily extend the available print styles by a simple plugin which implements your own style. The resource calendar now uses the correct time zone. Journals now also work with the resource calendar. KOrganizer should now work with all foreign encodings (it uses kind-of-utf8 as specified in the rfc 2445), also for group scheduling. I just submitted that patch this morning, so if something breaks on your next kdepim update (in particular on systems with non-western locale), I'm the one to blame (please also tell me about such problems so we can fix them). I also implemented moving multi-day items (items with a time range that go over midnight) in agenda view. There is still one little crash in there, which I need to resolve before the release... Read More

This didn't seem to work first time, so I'll try again: I did a major reorganisation of the code just before the freeze hit. This caused a lot of breakage (eg. the wrapper classes were borked, as was KPart support), fortunately things are working again now. One important change is the use of separate classes to handle proxies for QVariant types and opaque pointers, this makes the code a hell of a lot easier to understand. Now that the structural stuff is done, Ian Geiser's SQL bindings seem to be basically working (though the QObject wrapper class needs a couple of bugs squashing) so the only thing that's left actually broken is the QPainter wrapper class. All in all, this code is looking good for the 3.2 release. Read More