KDE Blogs 

Aaron was interested in what I thought needed doing with KDE/ruby and I mailed him this to do list the other day. Here it is in case anyone else is interested. Read More

Since Licq got integrated with the rest of the KDE desktop using KIMIface (nice work Kevin), it's inspired me to make a couple more changes to improve our integration. Now it's easier to link IM contacts with people in your address book, and you can use your calendar to switch your IM presence. Read More

Today was the first day of the Ubuntu conference in Sydney. It opened with Mark Shuttleworth reviewing the last release and looking forward to the next. I took some notes which are not proof read or spell checked in any way. Next Matt Zimmerman ran an Ubuntu brainstorm asking what would we like to make Ubuntu better. Somehow the hour filled up quickly. After that the day was 8 solid BoF sessions, brainstorming ideas which will shortly be made into a specification. In expanding universe ogra and dholbach talked about how MOTU have pulled in packages from apt-get.org and how they can get more universe (MOTU) developers. There is now a KDE team page on the wiki, my plan is for KDE to quietly take over MOTU. The next session was the Kubuntu Roadmap where me and amu plotted plans for the next Kubuntu. KDE 3.4 was perfectly timed to come out with the Ubuntu schedule, chances are we won't have such luck with KDE 3.5 so we'll have to see what happens. I went to the Rosetta BoF next where Daf and Carlos decided on their 1.0 release in a couple of months. The Ubuntu build daemons are modified to search for any .pot and .po files and import them into Rosetta for easy translation by whoever wishes to help (and unlike some distros the result is then open for anyone to take back). KDE packages don't work with Rosetta yet because Rosetta assumes one directory with the .pot and .po files not the structure of kde-i18n which has a templates/ directory with all the .pot files and a directory for the .po files of each language. Hopefully Rosetta can be modified to take in kde-i18n. In toolchain roadmap we discussed the scary prospect of converting to GCC 4. This is a big change for KDE because of the new C++ ABI. Also KDE seems to be generally untested with GCC 4 and is rumoured to break in unknown ways, so that'll be fun. USplash seems to have been stopped in favour of a simpler system just doing cat foo.jpg > /dev/fb0. The Graphical Installer BoF was talking about possibly making an installer based just on the live CD (which would significantly reduce the cost of shipit, and at over 1 million shipit CDs sent I can see why they don't have the budget to make Kubuntu shipit CDs). Finding Packages discussed a program which would be a cross between gnome-app-install and click-and-run, a program installer focused on applications not packages and with fun features like screenshots and user ratings, would be cool to have something like that in Kubuntu maybe based on Kapture, but the actual package manager needs to be taken care of first. Finally language selector discussed how users could install language packages easily since at the moment you only get the one installed that you chose when installing (k)ubuntu. Adding something to gnome-app-install or its replacement seems to be the way here. Read More

Okay I finally started a blog @ kdedevelopers.org. So I now feel warm and fuzzy as I can write down my ramblings and share this with the rest of you. Isn't that "gezelli" ?

While usability guys normally can never sleep (because there is always something to complain about, if only the dream), they at least can laugh sometimes. As in a plane recently. A wonderful instruction table for emergency thingies. Perhaps this is only funny if "brace" is not in your vocabulary (in German then, you would read it "bratze"). However, what I saw reminded me more of something like audio terror.

KDE, the integrative desktop environment. I can't remember who came up with this but it is so true. By providing interfaces (kdelibs/interfaces) KDE enables choice without negatively affecting KDE interoperability. Read More

Today KDE Everywhere visited Sydney As did some (k)ubuntu hackers. But there's still time to visit the tranquility of the local Quaker meeting

So i have toyed around with Qt4, which led to a small application called "Knowledge" (Screenshots: 1, 2, 3). Once it's grown up, Knowledge is supposed to become a Wikipedia offline reader. Right now I need to find a good indexer and an easy way to generate HTML from Wiki markup (which is not trivial, since this also requires a TeX parser and a parser for special metadata, i.e. for drawing timelines). I'll probably hack up MediaWiki to work as a preprocessor (which I already started with, but it's a all a big mess right now) The second limitation is QTextBrowser: It's nice for enrichted text, but it's still fairly buggy and even once this is fixed, I really need a proper browser at the end of the day with whistles and bells. Maybe this will motivate me to help porting KHTML once we're getting there. Read More

So Adobe is about to buy Macromedia for 3.4 billion US dollars. Because of the possible antitrust investigation of the market for illustration tools company executives like the Adobe CEO and the Adobe Chief Financial Officer were eager to point out the strong competition with explicit mention of KIllustrator. Read More

In response to Aaron's blog about D-Conf I explained in my previous blog why I think a common configuration system is desirable. I didn't go into the issues that Aaron raised about FreeDesktop.org because I wanted to stay a bit focused and I found Aaron's blog a bit too confusing as to what his point with FreeDesktop.org actually was. This week I managed to dicuss the issue with Aaron on IRC and I think things have become more clear to both of us. Let me share me my new understanding here with you. What Aaron somewhat correctly noticed is that there is a certain aversion growing among some members of the KDE community against FreeDesktop.org . The reason of the aversion seems to be a fear that FreeDesktop.org could become an unstoppable influx of bad technology. Although it may be easy to dismiss that, I think there is indeed reason to be concerned. In my experience open source projects are vulnerable to well intended people adding badly thought out code or concepts. Once added to a release a project is often doomed to maintaining such code until it is possible to drop it at the next major version. It happened to KDE and, acoording to Havoc, Gnome hasn't been spared either in this regard. There are two factors that make this a bigger problem with FreeDesktop.org. Within a project like KDE there tend to be developers around that are comfortable enough to challenge bad ideas before they end up in a release, such challenge is often backed up by the reputation that the challenger has build up in the project over the years. But within an environment like FreeDesktop.org such safeguards are much less likely to work, challengers run the risk of being branded one-sided agenda-pushers and a reputation among developers of project A is less likely to bear any weight among developers of project B. The other factor is that KDE can filter contributions based on the "show me the code" concept: show me the code first and then we can discuss whether it's suitable for inclusion in KDE. Although tempting to use the same approach in relation to FreeDesktop.org as well, I think that for a FreeDesktop.org project to be successful it's more important to build a solid mutual understanding about the problem and the direction to venture in before any code gets written at all. Having code out there without a solid mutual understanding only flames the fear that the codebase may not address the right problems and concerns but will somehow still invades other projects. If the above is the problem that faces FreeDesktop.org, the question then becomes what we should do to let FreeDesktop.org overcome these problems? I think the first thing here is to understand and acknowledge that there will be FreeDesktop.org projects that are bound to produce very bad technology, be it misguided standards or badly written software. This is no different from KDE, we have large kdeplayground repositories, formerly known as kdenonbeta, full with software that is most likely never to see the light of day in a KDE release. Still we cherish the kdeplayground repositories because once in a while, out of maybe 20 failed attempts, one piece of software emerges that is truly worthwhile. And just as we have learned in KDE that along with such a success we have to deal with a fair share of failed attempts as well, FreeDesktop.org is likewise doomed to produce the really bad in the shadow of the really great. So now that you know that FreeDesktop.org is going to produce some really bad standards and software, how are we going to prevent such bad technology from ending up in your software? There are two answer to that. The first one seems trivial and childish but is probably the most important one nonetheless: If you don't like it, don't use it in your software. It's important because the value of shared technology comes from the fact that it is shared. The fact that it is commonly used makes it extra valuable, if it isn't used it's sharing value drops to 0. Developers working on to-be-shared technology who realize this, will also realize that they will need to make a real effort to reach out to others to adopt their work for the sharing value to materialize. [1] The second way to prevent bad technology ending up in your software is by being actively involved to make sure that the right technology decisions are being taken. After all, it's your software we are concerned about and you know probably best what the technological requirements and constraints are for your software and what, from the perspective of your software, makes the difference between bad technology and good technology. So go out there and make your concerns heard. If you don't raise them who will? In all this there is a large responsibility on those who work under the FreeDesktop.org banner. There is a responsibility on all of us working under FreeDesktop.org to reach to others who could be affected by our work, to take note of their requirements, to acknowledge their concerns and then to work together really hard to address all that and make things work for everyone. I think it was Aaron's point that this sometimes doesn't happen enough. I think the above explains a major problem that FreeDesktop.org faces and how to deal with it. I would also like to point how not to deal with it. That is by looking at FreeDesktop.org as a standardisation stamping organisation that blesses technology that everybody should be using. FreeDesktop.org mission page puts it like this: Read More