KDE Blogs 

The "nods in agreement" comment at the bottom of this post is required reading. For all of you. Go Eike.

I think the whole discussion can be simplified with three points that hopefully everyone can agree to: In the next 12-24 months the only way to get a somewhat competitive desktop is to pile up code from all sources, including kde and gnome, and try to integrate them somehow If you think about the architecture of a desktop in 5-10 years, this mixture of pure C code, Gnome/Glib C code, KDE C++ code, Python, Bash scripts, maybe Mono C# code etc, all with different API conventions and wrapped by various wrapping mechanisms, all that sounds like a horrible nightmare that no one really wants Whether you like freedesktop.org or not depends on whether you want to have a usable desktop soon (thus today's desktop has a high priority for you and the future a low priority), or whether your goal is to have the best desktop at some point in the future (future: high priority, today: low priority) Make your choice.

What's up with freedesktop.org? Daniel says KDE people don't care about it, Ian says we have to abandon it. I say let's embrace it and make it what it's meant to be, a common building block for all desktops, KDE, GNOME and whatever else. Read More

freedesktop.org is a website. Really! It contains code and documentation. We could use some of that for KDE, if it suits us. But KDE is a volunteer effort, and we don't have to read any particular website, nor use any particular code, nor implement any particular specifications. Read More

I have only one thing to say. kde-core-devel mail: one reply - from myself, one 'good work' on IRC, one 'I don't care, go away' (hi coolo) on IRC. desktop-devel-list (GNOME) mail: seventeen replies, all up, and many 'rock on's on IRC from GNOME hackers. That is all. Read More

I've started taking another look at how to best add support for XPath to KHTML. I've got a bunch of code I'm busy reexamining that lets you define an AST for XPath. It needs cleaning up but I think it is a decent first cut. Read More

In the beginning it was a neat idea. They wanted a common set of standards for interop on the desktop... Then somehow it all went wrong, somehow implementations started to pollute these standards. This has caused quite a quandary, now somehow we have these standards that are bound to technology, some of which we could argue is pretty poor technology. IMHO this is reason to abandon efforts to follow these standards until they become standards once again, instead of implementations. Read More

Nothing big, I just created two importable khotkeys mouse gesture settings for download mimicking some of the Mozilla and Opera mouse gestures. Feel free to suggest and contribute more. Also a couple of Mozilla/Opera mouse gestures are not realized yet since I don't know which way a mouse gesture would ideally affect an element (ie. link, image etc.) it is hovering. Read More

Most functions do not need more than one return value, but when you need more there's no easy way around it. Java has this problem, functions are limited to one return value, and in my experience it is often complicated to get along with this limitation. In most cases you either write more functions than necessary or you need to create a additional classes that need even more constructors, accessor methods and documentation. C++ and C# allow multiple return values using pointers and references. This solves the problem, but I think it feels wrong and especially the C++ syntax does not create very readable code. So I am going to show you an alternative, derived from Python's tuples. But first the existing syntax variants and their disadvantages: Read More

so, yup, i started ripping out parts of kopete's oscar plugin last night. The first thing to go was the old Kit API and so the AIMBuddy and AIMGroup classes are gone. abracadabra and poof. :) However, this means that contact list handling is completely broken right now. good thing i'm doing this in my own branch. :) Read More