KDE Blogs 

On Sunday we held the first Kontact Bug Squashing Day. A couple of core developers met on IRC and tried to fix some Kontact bugs. We started with 431 open bug reports (Summing up the reports of kontact, kaddressbook, kmail, knode, knotes and korganizer) and ended with 419 open bug reports. This doesn't sound too impressive, but we were able to address some of the remaining major problems, so all in all it was a success and not to forget it also was fun. Read More

Yeah, im insane... but you can. Check out cvs:[kdenonbeta/applets/kjsapplet] from cvs and build/install it. Next comes the fun part. There are 3 files, an .la file, desktop file and a js file. The desktop file is the same as they are for normal kicker applets. The la file is a bit more interesting, this is here to fool KDE into loading the javascript properly. Ideally we can make this go away in KDE 4 or 3.3 at the earliest. The la file must match the library name in the desktop file and must be unique on the system. This will get installed into the $KDEDIR/lib directory with the other.la files. The last step is to write your ECMA Script :) Read More

Did users ask for Expose? Yes, they actually did. Most likely they didn't think of this kind of solution, but its intuitiveness even though it is an unpreceded feature, as well as the positive feedback shows that it is something which was wanted. The problems for which Expose is a solution are: How can I find a window by its look? and How can I get a quick overview over all of my desktop(s)?. There already exist several approaches to solve one of those two, Kasbar's windows thumbnails tooltips, KPager desktop thumbnails, OS X's genie effect for minimized windows, to name but a few. Expose is innovative in that that it takes the technical capability of Quartz (smooth scaling of whole windows) for offering a combined solution for both problems at once, giving an overview over the whole desktop as well as allowing users to recognize individual windows without much of additional abstraction. With Expose Apple is here leveraging some backend features they previously introduced to OS X for offering a completely new user experience. The same is what KDE is starting to do now. Before the work within KDE was mostly focussed on the backend, the framework, building flexible and easy to use tools for developers. This backend is now being leveraged by more and more applications, Konqueror and Kontact being the most apparent examples. We can now proceed leveraging KDE's backend while trying to solve multiple existing concerns by users. In the best case this will offer innovative and practicable solutions for all users. In the worst case we will still have examples of the power of KDE's backend. Most important is that we make potentially useful (combinations of) existing features visible and accessible to users. I'd like to show several examples using new components which will be included in the upcoming KDE 3.2: The first one is Khotkeys2, included due to the never stopping stream of requests for mouse gesture control in Konqueror (a la Opera). Khotkeys2 offers support for custom shortcuts and for custom mouse gestures system wide, not only in Konqueror. Combined with the within KDE widely used DCOP this will allow users to optimize their workflow. This new addition is potentially usable in innovative way by combining mouse gestures with alternative pointer devices like touchpads, tablet system and many others, giving access and control to parts of the system which were not as accessible with the previous pointer support alone. The other one is the Universal Sidebar kicker extension. By itself, being exactly the sidebar users see in Konqueror already, it might not be very interesting. But the potential applications for the Universal Sidebar as a globally acessible area like the tasbar are manifold: Read More

The main problem is to find out what users want. Did you know whether users will like Expose or they will use KXmlRpc before they have been implemented? I don't think so. Did users ask for Expose? Unlikely. Can we know whether WinFS's way of searching files with meta-data queries will replace today's file systems? No. All I know is that it sounds useful, and that if it is a success KDE will look pretty outdated with its file dialogs. Read More

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