Category: KDE

I love you, too.

I went to the theatre tonight to see a modern interpretation of Dante Alighieri’s Divina Commedia. Parts of the play were rather beautiful, with singing and acrobat acts, the longer monologues I found rather … long. So let’s talk about KDE’s release schedule instead.

There are two interesting things to note. First, if you’re running KDE’s SVN trunk/, and you haven’t done it yet, upgrade your Qt to one of the pre-releases of Qt 4.6. Starting on Saturday, we’ll allow changes to trunk/ that require a Qt 4.6. There are two important reasons for requiring Qt 4.6:

• Qt 4.6. has some rather nice new features. One of the more fancy news in 4.6 is the addition of Kinetic, the new animation framework in Qt. There are also rather huge improvements in QGraphicsView, so overall it’s well worth upgrading.
• Qt 4.6 is essentially what people will use with KDE 4.4. Distros shouldn’t hold back shipping Qt 4.6 only because we didn’t test that extensively with our code base. So we (the release team) rather decided to require Qt 4.6 starting Saturday, so we’ll be able to weed out compatibility problems in our own code base and we can point our friends in Oslo to possible problems and thereby help releasing a rock-solid Qt.

For those not yet knowing all the Git commands and Qt’s path on Gitorious off their head, here‘s how you can track Qt:

git clone git://gitorious.org/+kde-developers/qt/kde-qt.git qt-kde

So requiring 4.6 is a good idea. The drawback is that this means that KDE cannot release 4.4 until Qt 4.6 is released (our policy is not to depend on unreleased versions). The Qties have promised to deliver on schedule, so we stretched ours a bit. This means that the next KDE release (4.4) will be two weeks later than initially planned, and out in February. In more detail it looks like this:

• October 10th, 2009: Trunk depends on Qt 4.6
• November 4th, 2009: Soft Feature Freeze
• November 25th, 2009: Hard Feature Freeze
• November 25th, 2009: Message Freeze.
• November 25th, 2009: Tag KDE 4.4 Beta 1
• December 1st, 2009: Release KDE 4.4 Beta 1
• December 1st, 2009: Documentation/Handbook Freeze
• December 16nd, 2009: Tag KDE 4.4 Beta 2
• December 22th, 2009: Release KDE 4.4 Beta 2
• Januari 5th, 2010: Artwork and Bindings Freeze
• January 5th, 2010: Tag KDE 4.4 RC 1
• January 6th, 2010: Release KDE 4.4 RC 1
• January 19th, 2010: Tag KDE 4.4 RC 2
• January 20th, 2010: Release KDE 4.4 RC 2
• February 3rd, 2010: Tag KDE 4.4
• February 9th, 2010: Release KDE 4.4

So you’ll still be able to install 4.4 for your dear before Valentine’s day and spread the Free Software love this way. Isn’t that divine?

One of my favourite utilities is filelight. Filelight helps you identify the big consumers in your filesystem, it can help you answer the question what’s eating your harddisk, and it does so very efficiently. Just today, I had, on my root partition, far too little free space. I knew I had quite some GB left, but got a disk full warning. First reaction: “WTF?!”, second reaction: fire up filelight to find the offender. Filelight quickly showed me that about one third of my root partition had vanished in /var/log, and in four files to be precise. A quick

echo -n > logfile.log

and hitting “rescan” on filelight showed the problem was solved. (Solved for now, I still need to check what made my logfiles blow up like this in only a matter of days. Filelight is one of those applications where I, as someone who tends to look very critical at software, just think “it’s finished”. It’s a small, rather self-contained utility that does one job very well: analyse space consumers on your filesystem. Thanks Max and Martin for bringing this wonderful utility onto my desktop. It’s a real pleasure to work with (of course the rainbow color mode is my favourite).

Kevin blogged about the porting of KMail to Akonadi. He, Andras and a couple of other KDABians are splitting KMail into smaller components that combined make up an email client. Those components are then ported to using Akonadi. The end result is a set of widgets you can remix to create a nice email applications. Since I’ve been working on Lion Mail, I’ve got some ideas how this stuff relates to mobile devices, and I was also eager to give the akonadi port of KMail a shot. Till and Kevin gave me some pointers where to begin, and I hacked up a small demo that shows how these components work inside Plasma. It took me one late night hacking session until I had a partly working folder and message list in a Plasma applet. Then I went to bed. After getting up, I caught Kevin on IRC to help me with my confusion, and the problem why the folderlist worked, but the message list didn’t show anything. Kevin advised me to uncomment some line, but when I looked at those line numbers, they were whitespace. Strange. After some minutes (and half of my morning coffee) I svn updated, recompiled and it just worked. Turned out that Volker had noticed my commits in the morning and fixed my code to work. Awesome. :-)

I’ve created a screencast showing this.

There’s also an Ogg/Theora version of the video
available.
This applet is kind of orthogonal to Lion Mail, but it’s really interesting to see how easily we can share code between Plasma (and thus mobile devices) and “traditional” KDE applications. Of course using the KMail widgets means, that it’s only rather shallow integration between those two, you don’t, for example, get the full Plasma theming or input models that are interesting for mobile devices.

Ladies and Gentlemen, We did it! We’ve released a fantastic set of applications, a beautiful and organic desktop that enables the user to do a couple of things that were previously simply not possible in this form. I was particularly intrigued by Jos’ KDE 4.3 screencast (the one you can see in the announcement page). Such a screencast always gives a bit of a personal feeling and it shows what other people do with the software were working on, often it reveals new and cool and useful features, it did to me.

Right now, I’m anxiously awaiting the reaction of those people out there. Will the users like what we’ve created? Is the direction we’re taking really reflecting in the user experience, and do people out there value our approach, our ideas?
Until now, only very little people have seen KDE 4.3. It was in freeze for quite some time already, and there have been some reviews around on the net (most of them rather positive). Many people, however will not try the release until we actually say it’s stable. So today, another big wave will install KDE 4.3 and see it. Over the next months it will come with many of the Linux and BSD systems so an even wider range (say those that stick to standard distro packages) will give it a try, and probably also many people that haven’t used KDE, or Free Desktop systems before — many of them attracted by the Appeal and Freedom that KDE – The Software and KDE – The Community provides.

In the release announcement (which has been written by the excellent Jos Poortvliet), the message is rather careful: This is an incremental release, many (in fact about 30 bathtubs full of tiger tails ;-)) small annoyances have been corrected, and new features added that really make applications and the desktop shine. The rock-stable development platform that is KDE 4 supports this well, and has in itself gotten nice additions, polish and many fixes. Overall, the performance and polish has improved, resulting in a smooth and attractive user experience. In short: KDE 4 is mature, and it’s alive and kicking. (Join the team! :-))

Congratulations, my fellow gearheads. Have a mango-carrot juice, a beer, a mango lassi or a vintage port to celebrate!

Recently, the discussion whether to make KDE the default desktop on openSUSE has been raised. The situation bears some historical meaning, and has also brought up some misconceptions. Let me try to give a bit of an overview of it, and put things into context.

The numbers

Last year’s user survey has shown that a large majority of openSUSE users uses KDE, the distribution, according to this survey, is 68.3% use KDE, 26.9% use GNOME. The recent entry on features.opensuse.org (a tool to track feature requests by the community, which also has a voting system attached to prioritize the proposed features based on how important they are to the community). At the time of this writing, 15% are against this feature, 68% voted for this feature. The request to make KDE the default on openSUSE is by far the most popular entry (second most popular following up at 175 net proponents).
Those are very clear indicators of the popularity of KDE in openSUSE. Both confirm that KDE is the desktop of choice for most openSUSE users.

The History

SUSE Linux, and openSUSE (its follow-up) have traditionally been very KDE-centric, many KDE developers ran SUSE, many inside Suse ran KDE, basically Suse was a KDE-centric distribution and all was fine. When Novell bought SUSE Linux, and roughly at the same time Ximian, things started to change. Three years ago, some people inside Novell planned to ditch KDE, meaning to lay off all KDE personnel and move on with the GNOME desktop only. That happened relatively short after Novell had bought both Suse and Ximian, it has been said that those events are closely connected. The community, and many people at SUSE have made clear that they wouldn’t accept this decision which eventually lead to Novell backpedallling and starting to “live with KDE”.
Also, over the last years, openSUSE moved further and further away from being the home to many people inside KDE, and the best distro you could choose when looking for a KDE-based desktop. Compare this screenshot with this one, for example.
The first step was making KDE not the default anymore, offering a list of options during installation. At first, KDE was still on top of that list, at some point it was moved to the second place (which of course was done to reflected the alphabetical ordering). The dialog does not have an option pre-selected. (Also, Novell’s enterprise offering, SLED has moved to GNOME as default desktop. But this is not so much about SLED, but about openSUSE.)
In any case, the development of openSUSE position towards KDE have lead to many people moving on to alternatives. Quite some KDE developers I know, who have previously been avid SUSE users have reconsidered and are now running something else.

openSUSE and community

Nowadays, Novell is trying to turn openSUSE into a project which is fully managed by the community. I think this is a great opportunity, also for upstream communities to get more involved with a distribution, but of course it goes both ways. Giving users the tools to create software (such as the excellent openbuildservice) and the means to take part in decision-making processes (through features.opensuse.org for example) goes a long way to make community-developers (those not receiving a pay-check from Novell) more comfortable. Conversely, if those developers get the feeling that their work is welcome, but their input is not, and that their work is not equally valued to others’ work, you’ll lose those exact same people.
In the case of making KDE default on openSUSE, Lubos Lunak explains this really well, so instead of re-writing his words, I’ll just quote him:

An important point that many people here fail to realize that this is not asking for granting a special priviledge to KDE. In fact, it is asking for removing a special priviledge that makes many in the KDE community feel that KDE is treated unequally in openSUSE. In all other cases, when there is a clear preference, it is selected as a default, sometimes not even offering the user an easy choice. In this case, however, while KDE is the clear choice in the openSUSE community, it is not treated the same like in other cases. Instead, GNOME is given a priviledge that a preference must be explicitly expressed here, and this priviledge, to my knowledge, is not given to any other openSUSE component. No other non-default browser, mailer, shell, filesystem, etc. has this luxury. This is interpreted by the KDE community as a message from openSUSE that it values GNOME more, that GNOME is forcibly pushed into openSUSE and that KDE is not equally welcome in openSUSE. The openFATE request, in practice, asks for removing this GNOME priviledge and fair treating of all openSUSE components.

From Lubos’ email, it’s pretty clear that the status quo is not OK for a large part of the active contributors to openSUSE.

Vincent Untz, Board Member at the GNOME foundation (while acknowledging his bias) has proposed to do another vote on this particular issue. I think that’s a very dangerous thing to do, because it might be interpreted as “We’ll keep repeating the vote and changing the mechanism until the result suits us”. Joe has already initiated doing another user survey. While a user survey does have a lot of value, only surveying, and then not following up on the results risks credibility.

The case of openFATE (the application running behind features.opensuse.org) needs to be looked at as well. In his introduction to openFATE, Michael Löffler, Product Manager at openSUSE, announces: “We’re looking forward to receive more qualified feature requests to make our openSUSE distribution and the project itself fit your needs better from day to day.” My understanding is that FATE (features.opensuse.org) is the preferred way to receive those feature requests, based on the assumption “If you ask, you also create some obligation to take the answers into account. Otherwise, nobody should waste others time with asking, it’ll not be more than a lip-service.

The User’s Point of View

Why is a default so important to the user? In order to get as many people possible to install openSUSE, you need to make the installation process as simple as you possibly can. This means not asking the user too many questions, and certainly not asking the user questions he or she cannot answer. This is the reason why almost every operating system out there has chosen default settings. Default settings for a webbrowser (what appp is used to open links?), default options for ui-specific settings (colors, theming, for example). The general idea is, offer good default that suits the largest possible group of users in order to minimize the “total setup time” all users combined have to invest. It’s also good marketing practice: “Accommodate the largest group of your customers”.
Joe “Zonker” Brockmeier, community manager at Novell sees real value in not having a default, however. He points out “But limiting choice, in my opinion, isn’t the best option – the best option here is to do a better job at informing new users.”. I do not quite agree with the points, Joe made, though:

• By setting defaults you are not limiting choice. If that was the case, you should just not setup defaults at all, anywhere, and that would quickly show that it’s impractical to not offer defaults. Choice is about being able to choose an alternative, not about “inform yourself first!”. Gerald Pfeifer, Director Product Management at openSUSE, put it nicely as “Choice is not (necessarily) about not having a default; it is about the ability to choose.”
• The best option might be to do a better job informing users. I wholeheartedly agree that it’s very important to have informed users. There are two considerations to be made, however. First, you won’t, ever, get only informed users. Especially if you’re targeting new users to the Free Desktop, the complexity of switching to Free is already so high that adding another mandatory choice is only making it more difficult to install openSUSE. By not offering a default, you’ll force new users to
  • … do research upfront, and thereby increasing the real costs of installing openSUSE. (Costs measured also in precious “time it takes to get cracking”.) The problem is that even if you force users to “do their homework”, there will always be a non-zero amount of them not doing it. Some are too lazy, some don’t have the time, some simply learn by doing. For all of them, not choosing a default option means increasing the entry barrier to openSUSE. The general net-effect is that some drop-out during installation because it takes too long, is to complicated and requires domain- or expert-knowledge.
  • … guess about what’s the best choice, which in turn causes uncertainty (“Which option is the right one? What is better for me? Will I be able to come back on this decision? and afterwards: “Did I screw up on that checkbox during installation?”, “What have been the implications of this checkbox?”) In other words: You lose clarity, you force more mental strain onto the user.

Another important point for me is that only one such question (“What desktop do you want?”) adds the requirement of domain knowledge. The question is fundamentally different from “what is your timezone?” for example, so for a complete dummy, it’ll not be possible to make sure all questions are answered correctly.

Michael Löffler notes that only a relatively small part of the openSUSE users are new (about 6% according to the survey), and concludes that therefore, a default setting isn’t all that important. This way of thinking will actually make sure you keep preaching to the choir. If growth of openSUSE is one of the project’s goals, the question “Why are only 6% of our users newbies?” would actually be one of the first ones I’d ask myself. Sure, it’s a chicken-egg problem, the approach to this kind of question is essential to growth, however. It could well be that the number of new users is only 5% because openSUSE is hard to install, because there’s no default choice, no clear support and no distinct identity.

The impression I get is that Joe Brockmeier wants to keep the status quo (no default, GNOME listed as first option) to not cause political discussion and disruption in the project, to keep people calm. That’s his job, and it would work if the current situation didn’t have major problems already. I’ve pointed out the problems for the end user, Lubos has pointed out the problems for the openSUSE-KDE community. It should be clear that this subject is not as easy as “We don’t want to alienate the GNOME developers, so we’ll keep the status quo”. Actually, I would not at all be surprised if the majority of GNOME-on-openSUSE developers would just see this step as catering to the largest user group. It might even have a positive net-effect by making people try harder when they see that the default choice is actually a reflection of what the majority of users want, not a seemingly random decision by executives. The best way to accommodate for a healthy community is not avoiding politics at all costs, the best way is showing a strong sense of fairness and creating a system where success (for example expressed in terms of the default choice during installation) is based on measurable vectors, in this case popularity among users. Make your offering the most popular by gaining the most users, and you become the default choice. That’s fairness because it’s transparant.

Conclusion

The numbers are clear, KDE is the preferred desktop of the openSUSE community. There is a formal request to reflect that in the installation process. Novell, and those with decision-making powers in the openSUSE team now have the opportunity to prove that features.opensuse.org is not just a lip-service, that the community does control the direction of openSUSE. Not having a preset for the desktop that is installed is hampering adoption of openSUSE. On top of that, keeping the status quo in the current situation will alienate many people, because it’ll convey the message: “However hard you try, we’ll keep doing what we want.”.

After Linuxtag had finished, a couple of gearheads went to Berlin Kreuzberg to grab some food and a drink in a quiet and not to crowded place. That didn’t really work out, as we didn’t think of Christopher Street Day. We quickly decided that it would be a fine alternative to have food and drinks in the streets and celebrated with another couple of hundred people until late at the night. As you can easily see on the photos, people were more than colourful, and it was a very friendly, laid back and fun event

Linuxtag itself was quite good, I was mostly there representing KDAB, but got some FLAs signed and also held a presentation on using KDE 4 on laptops and netbooks. I think I struck a good balance between technical background of power management related issues and things that are relevant to those who want to use KDE on those devices, and just want things to work (and possibly understand why they don’t in some cases). After my own talk, I attended Will Stephenson’s talk who put his salty fingers into some wounds we still have with KDE 4, and which are a problem for many user’s experience with the desktop. Besides the fact that not all of our cool technologies haven’t yet shown their full potential to the users, Will made a good point that we’re kind of sticking our heads into the sand when it comes to a really good web experience when using KDE. I agree that we can do much better, and that we need to do something about Konqueror (or our default web browser, anyway) not being able to render many web pages people out there in the real world use.

I’ll be staying for another two days in Berlin, then pay a quick visit to Kim and the pets at home before I’m flying to Gran Canaria for an awesome summit. See you there!

Protecting KDE from bad things is one of the primary purposes of the KDE e.V.. As a member of the KDE e.V.’s Board of Directors I got the special honour today to put one more piece of the protecting freedom puzzle into place by signing people’s Fiduciary License Agreements (or in short, FLA). The FLA is a means for the KDE e.V. and the wider Free Software community to be able to relicense code that has been contributed to KDE by people who are, one way or the other, not able to “fix the license” anymore. When relicensing code of someone else, we’re bound to pretty strict rules, all has to happen within the principles of Free Software. I’m not really firm on legal grounds, so I’ll invoke my fellow board member, Nijmegenaar and the new coordinator of the FSFE’s Freedom Task Force (congrats!) to explain those details. Go-go-gadgeto-Ade!
Carlo Piana summarises the purpose of the FLA in the following words:

Essentially, any developer holds the copyright of the software he/she authors, which means that for complex projects, any developer would have a say in any major decision regarding the software, with frequent problems in terms of flexibility and management (including litigation). The fiduciary licence aims at simplifying this process, by assigning the copyright to an entity as KDE e.V. which is not “scalable” and therefore provides sufficient safeguards as to the possible hijacking of the project for nefarious reasons.

I’ve signed about 10 FLA’s on behalf of KDE e.V. already, with more to come. If you’ve contributed code to KDE (even if it’s just a little), please drop by the KDE booth at Linuxtag and sign your copy of the FLA. I, or our friends from the FSFE (or Ade :-)) can explain to you in more detail what it means, and why it’s important to sign it if you’re still unsure. We’ll also be bringing a stack of FLA forms to the Gran Canaria Desktop summit in a bit more than a week’s time, so grab your chance, and protect your and our Freedom!
Update: Meanwhile, I had the honour to have Matthias Ettrich and Martin Konold (the two founders of KDE) sign the FLA.

I arrived in Tuesday for Linuxtag. This time, however, I’m not mainly here for KDE, but for KDAB where I’ve started working in May. KDAB is a company focusing on Qt technology — consultancy, development and training. It didn’t take long getting used to my new colleagues, as I already knew most of them. Quite some KDE people are working for KDAB (in fact it was founded by Kalle, one of the first “gearheads”). Working for KDAB is actually quite interesting, as it’s a virtual company. That means that we have our morning coffee on IRC and jabber, and that most of the people are working from home. There is this odd group in Berlin who found that an office would be a cool thing to have, and that it’s best situated in Kreuzberg, one of the more fun parts of the city. As I’m working with some people in Berlin, I’m plugging into the weekly catch-up-with-everybody meeting via webcam and VOIP, which works quite well. It does give me that warm, fuzzy feeling of having actual social contact once in a while, while I still don’t have anything to do with traffic jams, commuting and all that jazz.
Kreuzberg, where our Berlin office is located, is a great place for an office, it’s very easy to reach, there’s plenty of really good and inexpensive food around at the office, and many cocktail bars. It also makes a great place for hackathons, and my company is KDE-friendly enough to host regular meetings of all kinds. Actually, I don’t think there’s a place that has hosted so many KDE sprints already, with certainly more to come.
While not all we do is related to Free Software, much of the work I get in touch with is, and I think that’s very cool. Working with and on Free Software is a great motivator for me, and it’s good to see Free Software providing a viable business model.
So this week, I’ll be hanging around at Linuxtag (we have a shared booth with the Qt Trolls, right next to the KDE booth). On Saturday, I’ll be presenting about KDE on laptops and netbooks, make sure you don’t miss that talk.
After Linuxtag, I’ll be staying for a couple of days here in summery Berlin to catch up more on work-related things, and then I’ll pay a brief visit to Kim, the cat and the chinchilla’s only to depart to Gran Canaria. Thanks to my employer, flight and hotel is taken care of by KDAB. Thanks!