Entries by Mark Kretschmann

A friendly user has today created a screenshot of the latest Amarok from Git Master. I was rather surprised that it actually looks fairly decent on Windows (had expected worse things), and the user even said it also works pretty well, with the new Phonon-VLC backend.

Anyway, I wanted to share this with you, but please keep in mind: This is a preview of the next Amarok version. Some things (like the new toolbar) are not yet fully finished, so please don't complain about that.

A while ago I had written an article about the dangers of "micro-options" in software. Like many articles about usability, this one was discussed somewhat controversially (which is good in a way), but overall I did get a positive reception, even from a professional usability expert.

While this article was perhaps interesting, there was no "proof in the blog pudding". Let's be honest here, anyone can claim the wildest things in blogs, which may be true, or not. I did however stumble upon an interesting connection between psychology and usability, which appears to back up my speculations. The connection is this:

The Paradox Of Choice

Have you ever been in the following situation: You're in a supermarket. You want to buy a salad dressing, and the timing is somewhat tight. Guests are waiting, the usual...

Alright, found the "salad dressing" section (which can he hard in itself, in huge supermarkets). So, not much time, let's choose something that looks yummy, and preferably not too fatty! So, what do we have here? Vinaigrette, Blue cheese dressing, Caesar dressing, Honey Dijon, Hummus, Italian dressing, Louis dressing, Ranch dressing, Russian dressing, Tahini. Hmm. Nice choice. Let's go for some Italian Dressing, I like that one. Wait, there are three different brands of dressing, each of them offering further varieties of this product. Chef's Choice, Low Carb, Lite, Very Lite, and hey: the Special Edition!

Here is someone who can explain this problem of choice much better than I could ever do. His name is Barry Schwartz, he's a professor of psychology, and he made one of the best TED talks ever (according to the founder of TED himself):


TED Video: Barry Schwartz - Paradox of Choice


I very much recommend watching this video. Few have been disappointed by it, and I suppose you might find it enlightening too. It does explain many phenomena in our modern life in a surprisingly simple way. One of them can be translated to usability: Too many choices can reduce the user's satisfaction with a software product.

I'd be happy to read comments on this article, be it positive, or negative. Discussion is important, so I think we should do that. But please, do me one favor: Watch Barry's talk before commenting. Thanks

Dear Amarok and KDE users,

I'm sure that you have heard of the terrible earthquake disaster that has happened in Haiti. Current estimations of deaths range from 100,000 to 200,000, and this number keeps rising. What we are looking at is very likely one of the worst natural disasters of the last 10 years.

I would like to encourage our users to help Haiti in this situation, if you can. One way of doing this is by sending donations to international humanitarian groups that support helping Haiti. I'm sure there are other ways, if you know some concrete examples, please add a comment.

Please do not voice your opinion if you have any bizarre theories (be it from religious motives, political fearmongering, conspiracy theories, etc) about how this disaster happened. I've heard many of them, and there is no need to hear any more. This article is only about helping, but not discussing backgrounds.


Thanks.


Disclaimer: I do not speak for the Amarok team, nor do I speak for KDE. This article is a private matter.

Here's a little story I wanted to share with you. It's so bizarre, you might not believe it when you read it, but it really happened


Some back story:

A few months ago Amarok had migrated to Git, and then Konversation had migrated too. We had to write a special "commit hook" script for making the commits show up on IRC, via the CIA bot. This script was running on our Amarok server (called "Kollide"), and all was fine. At some point then we migrated our server to new hardware, as the old contract had expired. That also went really well.


What happened later:

At some point the CIA bot started to print everything twice. Yes, every single commit, all duplicated. I guess you can imagine how annoying that was. So we tried to debug this for weeks, looked at all scripts, at Gitorious, and whatnot. Noone was able to spot the bug, it was a mystery. Two days ago then we discussed this problem again in our #kde-git IRC channel, with Jeremy Whiting, and Eike Hein. Basically we were close to giving up on the whole thing. For fun, Jeremy said something like: "Hmm, what happened to your old server, btw?". That got us thinking. Then Eike compared the IP addresses of the server that sent out the commit message, and what did we see there: Two different IPs. What had happened:

The old server (we like to call it our "Shadow Server" now) had continued to run happily, because the hoster had forgotten to switch it off. So it was still running our web site, all sorts of other stuff, plus this little commit hook script!

When we realized what had happened there: There was just one possible reaction: Headdesk


Don't know about you, but we found that quite bizarre and funny, as noone had anticipated that (not even our admin)

This is the second part of my series of articles about "good music", which was originally planned to become a series of three. In the first article of this series I had talked about Progressive Rock. The plan was to do a follow-up on Electronic Music, and then one on Classical Music, but somehow I got inspired today to write about Rock Music instead, so I'm changing the plan a little.

As a preface I should again say that this is of course highly subjective. Tastes differ wildly, and talking about art is especially subjective. Why am I writing this? As a developer of a music player I simply get to hear a lot of music (all day, basically), and I've always been fascinated by music, although I'm personally not a musician. So, take all of this with a grain of salt. What motivated me to write this second part is that I did actually get some very nice feedback on the first article, including a fellow KDE developer talking to me at the Gran Canaria Desktop Summit about this article, which I thought was really nice. Apparently there is some interest in talking about music, so let's just do that

Now I should explain why I originally didn't plan to write about Rock Music. The reason is a bit weird: I am somewhat ashamed of admitting that I do enjoy Rock, simply because there's so much crap in this genre. Again, this is highly subjective, but I just don't consider run-of-the-mill Rock very exciting. However, some bands managed to do Rock with a twist, either by adding components of other genres to it, or simply by being freaking good. Most of these "freaking good" bands also are versatile though, and they do incorporate different styles into their music.

Queen

It is pretty hard to describe Queen briefly. It's also pretty hard not to hit superlatives when talking about them, because they were very super in many regards. I personally consider Queen the best rock band of all times, that's probably the best way to sum it up. Queen also happened to be my first "love" in music, and to this day I love them just as much as I did when I was 14. What made them so special? First of all, their singer Freddie Mercury was simply as good as singers can get. Incredible vocal range, fantastic and unique voice. Freddie Mercury died in 1991 from AIDS, one of the first prominent victims of this virus. Back then this caused quite the media stir, as Freddie was more or less openly gay, and the media tried to do the best they could to explain that "the guy died because he was gay". I'm missing words to describe this stupidity, so let's switch to Brian May, their guitarist. May is in fact "Dr May" now, as he has recently completed his PhD in astrophysics, and he's currently listed at #39 of Rolling Stone magazine's "100 Greatest Guitarists of All Time". It's hard to call the man anything else than a genius, if you have ever listened to his compositions and guitar work.

Freddie Mercury was able to switch effortlessly between Falsetto voice and Modal voice (what you would consider the normal voice), without really pausing or causing a hitch in the transition. As far as I know, this is pretty difficult to do, and not mastered by many. In my mind, I always had the image of him using his voice more like a musical instrument than just a voice, much like a trumpet. He was able to start deep, and then lifting it up, higher and higher. If you try that at home, chances are you'll end up with a sore throat next morning.

If you care about music at all, you should listen to some Queen songs. Some recommendations for especially good songs: "Bohemian Rhapsody", "Who Wants To Live Forever", "The Show Must Go On".

U2

This band is a bit of a strange bag. I have some sort of love/hate relationship with them, caused by a moral dilemma: Their music is among the best you can get. Their believe system is comparable to a fruit cake.

U2 is an Irish band, but these days they are more like a worldwide corporation. Their singer Bono is a bit of a controversial person. On the one hand, the guy is simply a good singer. On the other hand, he tends to get a bit over his head, meddling in politics, trying to cure world hunger, and kissing the Pope's ring. One of his latest escapades even made it to Slashdot. You be the judge if this man can be liked. My opinion: It's important to separate the personal from the professional. And professionally, this band simply is damn good. Bringing us to the next important band member:

The Edge, who is the guitarist and main composer of U2. I personally find him more likable than Bono, but all this is of little relevance. What is relevant to me is that Edge is a very good guitarist, with a unique style that is different from most other guitarists. His electrical guitar soli are rarely there for showing off, but more for creating a mood, and that he does masterfully.

It is important to note that most of U2's brilliant albums (they also made some crappy ones) were co-written by Brian Eno, who is widely known as one of the most influential persons in the music industry. My suspicion is that Eno is the true mastermind behind U2, as all albums with him tend to be masterful. The rest, not so much.

Some recommendations for U2 songs: "One", "With Or Without You", "Unknown Caller".

Honorable Mentions

Here are some more "rock" artists that I enjoy (they are all not classic rock'n' roll bands, but let's keep it at that):

The Verve

Guns 'N Roses

Pink Floyd

Frank Zappa

R.E.M.

I hope you enjoyed this article a bit, thanks for reading! And as always - I'd love to hear some feedback

Nice holidays and a happy Hackmas to all of our users, developers, and basically to everyone else too




PS:
There are two easter eggs hidden in this xmas blog article. If you can spot them, you deserve one extra "Happy Hackmas" from me

Some of you might have heard about the Malware incident that recently has hit our friends from gnome-look.org. While some of you might chuckle about it because it hit the competition, there really is nothing to chuckle about, because the next target could easily be us. In fact someone might be uploading a Malware component at this very moment. Noone could tell until it's too late.

So, there have been some discussions about possible solutions for this issue. Some have proposed that we add a review process to all of this, so that anything that gets uploaded gets a security check from some KDE developers. That's a neat idea on paper. But only there. This couldn't possibly work out, for two reasons: 1) Manpower - We simply don't have enough of that. 2) Responsibility - Who wants to be responsible for letting Malware slip through your fingers? This can happen to anyone, and it would be pretty embarrassing. I certainly wouldn't want to be responsible for anything.

Back when we designed the scripting system for Amarok 2 (QtScript, in-process), Ian Monroe and I realized that there isn't really any way to make it secure on a technical level. Sandboxing, automatic malware detection, flying cars - all this works somehow in theory, but in reality it requires some Bruce Schneier to do it, which we don't have (there is only only one Schneier, I guess). So basically we realized that the system would be unsafe, and that we would have to live with it. Amarok is very vulnerable to Malware scripts, because scripts can access most of Amarok, and Qt, and whatnot. Any Joe Schmoe could hack up a two-liner script that deletes your $HOME. So we accepted that reality, and tried to think of some other methods for making it all safer. What we came up with is this:

Mandatory Version Control

Basically our idea was that all Amarok scripts (and the same could help with other download components) would have to be hosted in a public version control system (VCS). This system could for instance be SVN, simply because it's relatively easy to learn, and we could use a central server for it. These are the three advantages that we'd expect from the proposed system:

Malware. With a VCS, it's very easy to tell who inserted Malware, and when this person did this. This fact alone would provide some accountability, and I think it might prevent a good deal of attempts of messing around with the code. And even if it happened anyway, it would be trivial to revert the change, and we would just ban the person who did this from ever committing to this repository again. Another positive effect is the sheer number of developer eyes on this code, which could catch many issues before they become a problem. Currently we have this #kde-commits channel on IRC, and some developers are watching it (if only to kill some time). I think something similar could work with this system.

Abandonware. One of the major issues we had with Amarok 1.x scripts was the sheer amount of forks. Developer A created script A1, then developer B came along, forked the same thing (in other words, copied the code), enhanced it a bit, and released it as B1. This left us with a huge amount of varieties of the same script, and noone could really tell which version was maintained at all. With a VCS, developer B could simply take over maintainership of script A1, if for some reason developer A stopped maintaing it (which happens all the time).

Crapware. Learning the VCS means an extra hurdle for contributors. This can be seen both as a disadvantage, or as an advantage, depending on the point of view. That's because learning something like SVN is pretty simple, and yet it would prevent very unexperienced programmers (who are also missing motivation) from starting the project, in the first place. But it's easy enough that it probably wouldn't prevent someone from doing it who really is motivated, which is probably for the better. So it might just work out in reality.

As an addendum, I should say that this system could only work if we enforce it, making it mandatory for all scripts and any kind of program code that is reachable via GHNS. Making this system optional wouldn't solve anything, because then a Malware person could still merrily go ahead with his/her evil intentions.

To sum it up, I think that this approach could really help us, and all that's missing is a practical implementation. We would have to work together with the kde-apps.org people (mainly Frank Karlitschek), and the GHNS developers, and then set up an official VCS repository (maybe KDE SVN, maybe something else). I'd be interested in hearing your opinions about this proposal, so please leave a comment if you have an opinion on it

Short article about a new project we started:

ColdStorage

What is ColdStorage? Well, basically it used to be a Vaporware project, started about two weeks ago, which is now no longer Vaporware. It started out with some of us KDE folks getting fed up with existing solutions for using Git as a backup tool (for backing up $HOME, etc). There are a number of existing projects that try to do the same, but I found none of them working, either not working at all, or not fully working.

So we thought, hey, let's give it a try by doing it ourselves. What we started with was a basic idea, a cool name, a Git repository, an IRC channel (#coldstorage on Freenode), two developers, and a bunch of code stubs. Thanks to Thomas Zander, we now actually have some code. Thomas managed to create some initial code for it basically on a Sunday evening.

Now, the project is still in very early stages, but in the FOSS spirit I wanted to announce it anyway, since my feeling is that the more people know about it, the more contributors we might attract, and the faster we can get it done. After all, what we want is a tool that just works, as quickly as possible.


Here's some more info about ColdStorage:

ColdStorage is a backup tool using Git at its core.

Written in C++, with QtCore.

GPL v3 licensed.

Multi-platform (in so far as Git is multi-platform, not sure how far the Windows support is).

Still in its very early stages of development, but the core functionality is there.

If you are interested in helping out, come join us sometime on IRC

Today I'd like to write about a topic that has interested me for a while, and at the same time tell an anecdote, about an event that I found fascinating. You might find it interesting, or not, but I guess some might like it.

To make a start, let's make a jump back in time, about one year ago. Back then, I had never met a real "VIP" in person. I had met a few "Internet-famous" people, among them Matthias Ettrich, and Alan Cox, but let's be honest here: While some of us FOSS people are well known in our Free Software circles, ask Joe Sixpack in a bar about them (or really just some guy in the non-FOSS IT area), chances are slim that they'll know them.

At this time I got an interesting offer for a software project, the nature of which is irrelevant to this story, so I won't disclose it. What I can disclose is that it had to do with Gibson Guitar Corporation, and I (along with two co-workers) was invited to a meeting in Berlin, for a presentation of the project, with the the boss himself, Henry Juszkiewicz (on this photo he was meeting Steve Wozniak). You may have never heard of Henry himself, but you sure have heard of Gibson, because it's basically a given that some of the artists you listen to are playing a Gibson guitar. Gibson is one of the biggest musical instrument manufacturers in the world, and if you like guitar music, you'll probably know that most guitarists either play a Fender, or a Gibson, or possibly both (many guitarists use multiple different guitars, depending on the thing they are writing).

Being a big music fan, I realized that I was about to meet the man who made the guitars played by Mike Oldfield, Pink Floyd, U2, you name it. I don't know about you, but this made me very excited (and nervous). I was wondering, how could such a person be in real life? Would he a be a chair-throwing tyrant like Ballmer, or arrogant and preachy, and would he talk to me at all (a lowly FOSS coder)? As it turned out, I didn't have to be nervous at all. Because the man is completely different from what I had expected.

What I met was a calm person, considerate, quiet, and very friendly. Henry knew all our names, he knew exactly what we did (he had used Amarok before), and he talked to us just like you would talk to any other person. It boggled my mind when the guy shook my hand, and said something like "Hey Mark, thank you for coming here! It's nice to meet a developer of Amarok, I really like this software." Bahm. Just like that. After a few seconds of disorientation, I started to talk to him, and realized that there was no need to be nervous at all. I wasn't talking to some VIP (although he is that), but to a normal guy, intelligent, witty and friendly.

Fast forwarding a bit in the meeting, I learned to know another side of Henry, no less fascinating: He was given a presentation of some audio gear, and evaluated the speakers. At the same table, there were three audio experts in speaker technology. Henry listened to the speakers for a few seconds, then went like: "Stop. Ok guys, these speakers here are... something. They aren't good though. What I want, is the best. Get me XY on the phone ASAP, he's the best guy for this job, I've worked with him before." Bahm. You should have seen the faces of the "experts" at the table. It's hard to describe the exact look, it was something like flabbergasted.


To sum it up, I've often found that really important people (not those who pretend to be) have the following qualities:

They are in that position for a reason.

They know exactly what they want.

They don't have to be arrogant, because that gets you nowhere. They prefer getting things done.

Hope you enjoyed this little anecdote

Many of you have probably experienced this problem before: You're using an IRC client (in my case Konversation), but then your desktop crashes, or you have a power failure, and then of course the IRC client crashes too. Some time later you log into your desktop again, fire up the IRC program, but damn, you've lost a part of an important conversation. Worry about this no more!

Fortunately, there exists software that's generally called "Bouncer" (or BNC). A Bouncer is basically a proxy server that handles the IRC connection for you. Instead of talking directly to the IRC server, you talk to the Bouncer instead, which relays everything in realtime to the IRC server. Modern Bouncers even support SSL encryption for added safety (I would recommend to use this). The advantages of a Bouncer summed up:

You can be connected 24/7 to the Internet, without actually having your computer running.

When you lose your connection to the Bouncer, you can simply log in again, and the Bouncer will even replay a log of all lost information to you, fully automatically. Basically it appears as if you had never been offline, things are all back to normal again.

On networks that don't offer an IRC Cloak service which hides your real IP address, the Bouncer can use a virtual host that hides your address. This increases security.

The Bouncer will automatically log you into all channels that you frequent, without having to join them explicitly again. This is handy if you sometimes use different IRC clients.

Some Bouncers (most modern ones) even allow logging in with multiple clients simultaneously. That's a killer feature. E.g. you could be logged in with your computer at home, and when you have to leave in a hurry, you can simply log in with any other computer (e.g. a Nokia N900) in the same session again, from anywhere in the world. Awesome, no?

How to set up a Bouncer:

Get access to a server somewhere that's always online. If you don't have your own, you could ask a friend. There you install the Bouncer software, e.g. shroudBNC or psyBNC (thanks to Kevin for doing this for me!), preferably with SSL support enabled. Then you configure your IRC client to connect to the Bouncer, exactly like you would connect to a normal IRC server. And voilà, you will now be able to enjoy IRC a lot more than before.

Here's a tutorial that explains the concept in more detail: psyBNC Tutorial


Enjoy


PS: There exist IRC clients (Quassel is a prominent example) that have similar functionality built-in. However, Bouncers will work with any IRC clients, e.g. Konversation, Irssi, X-Chat, and others.

Just a short article about something that has concerned me lately: Please take some time for choosing an application name, and think hard about it before coming to a final decision. I know that you are already giving it a lot of thought, this is not meant as bashing. But please consider the following:

Rekonq. This name only makes sense to users who are already familiar with Konqueror. Considering that Rekonq is trying to cater to the non-geek crowd, choosing such a geeky name is not a good idea at all. Noone besides hardcore nerds is going to understand it, and even then it sounds awkward (no offense).

Choqok. I know that this name has a meaning in the native language of its main author, but to the rest of the world, it has no meaning at all. Even worse, it's hard to spell (I mistype it all the time), and people are using joke names for it ("ShowCock") all over the Internet. There is a reason for that.

digiKam. Fantastic application, I guess many of us agree about this. One problem: The unusual capitalization is giving the press a headache. Paraphrasing a comment from Ryan Paul (Ars Technica author): "I wonder if I can get this past my editor..." That's because, in correct English, a sentence has to start with a capital letter. So it's impossible to use the name correctly at the beginning of a sentence, while at the same time being grammatically correct.

Now, before you start saying something like, "Yeah right, coming from the guy who named an application Amarok..." Yes, Amarok is an obscure name, but we were lucky to establish it as a brand. Also, we've been through some of the pain described above as well: Amarok was once officially called "amaroK". While we initially thought this looked cool, we did eventually realize that this kind of spelling gives you more trouble than anything, so we had to change it, which was painful.


Don't repeat our mistakes

So, I'm writing this partly because of vanity (let's be honest here), partly because reflection helps managing past mistakes better in the future, and also because some of you (KDE community) have asked about our experiences with Git. With this out of the way, let's go in medias res:

With Amarok 2.2.1 we have tried a new approach in release management, which meant a rather radical departure for us: The whole release cycle of 2.2.1 was pretty exactly 6 weeks long. While six weeks can be a lot of time, or very little time, in our case it was very little time, as we had set a goal of achieving three things with this release: 1) Features 2) Bug Fixes 3) Doing it all without causing regressions. To give you an impression of what we have done in these 6 weeks, check this out:

Amarok 2.2.1 ChangeLog

As you can see, the list is pretty long, especially so if you consider the short time frame. All of this made us proud of this release, perhaps even more so than of the 2.2.0 release (which used an ordinary long release cycle). One thing that contributes to our happiness about it: This was pretty damn hard to do, but in the end we made it. Did it go completely smoothly? Hell no. A lot of things went wrong, but it was a good learning experience. We intend to continue working in this style (one release every six weeks) for the foreseeable future, while incorporating some of the things we have learned (the hard way) with 2.2.1.

What went well:

Git. Yes, just this one word. Without Git it would have been entirely impossible to pull this off. Git allowed us to develop new features safely in feature branches, while at the same time working on fixing bugs, then merging it all together. Also, Git has managed to attract a lot more third-party developers (some of which have become team members by now). Some have argued that this was not an effect of Git itself, but rather of the (re-)growing popularity of Amarok, but I don't think that this is true. Here you can see an overview of all the Merge Requests (a Gitorious feature) that we have merged into Amarok since our migration to Git.

Motivation. Due to the ultra-short release cycle, all contributors could be sure that their code would actually see the light of the day, and in only a few weeks time. This makes a big difference for motivation, as compared to: "Yeah ok, I've made this XY feature, but it will only be used in 6 months, when we release."

Speed. Thanks to Git and other factors, we were simply much faster with developing than we had been with earlier versions. We got a lot done in these six weeks.

What went wrong:

Regressions. While I had claimed that we managed to do all of this without regressions, this wasn't entirely true. In fact we did have some nasty regressions, but we were lucky enough to catch them (some of them literally in the last minute) before it was too late. Clearly, this taught us a lesson: With ultra-short release cycles you need to put much more emphasis on quality assurance. This can mean: Unit tests, integration tests (unit tests don't suffice in many cases), and regular quality checks by users and developers. Personally I think that regressions can mostly be avoided by using smart processes, but of course you will never be able to rule them out entirely (try to prove a program's correctness mathematically, for fun). Anyway, this is something that we have to work on, but we have realized it, so all is good.

Quarreling. When you put so much pressure on a development team, there are bound to be some disagreements along the way. Developers often have big (planet-sized?) egos, and they will clash from time to time. The shorter the time frame you have, the more important it is to solve these arguments (ideally by consensus) as quickly as possible. For this reason we have a community manager in our team (Lydia) who takes care of such ego clashes, and tries to bring us back to a more rational path. This is not easy, I can tell you that, and Lydia could probably write a whole book about it at this point. One thing to note is that while we do often have arguments in our team, we try to keep them internal, and don't take them to the outside. This is done partly for PR reasons, but partly also because spreading bad vibes is simply bad mojo. It's ok to argue, but we try not to let this turn into a public flame war, because this is the last thing you need when you have to focus on creating a product.

That's it for now. Thanks for reading, and maybe also take a quick look at our Amarok 2.2.2 ChangeLog (at the time of this writing, our cycle is just about 50% completed, so I think it's pretty impressive already).

Yesterday Myriam and I attended the Kubuntu "Karmic Koala" release party in Berne, Switzerland, kindly hosted by Puzzle ITC in their very nice office. We did all sorts of funny things there, including a talk on Project Timelord (given by Myriam), some Amarok 2.2.1 goodness (presented by me), having pizza (including some very hot sauce), and... wait for it... beer!

All in all we had a jolly good time, made some new friends, and even talked about the possibility of having a Nokia N900 release event there in January (anyone interested in giving a presentation?)

Not very long ago, Aaron wrote an article about improving our user experience, stating that "Micro-Options Suck". Coincidentally, an article appeared on dot.kde.org only a few hours later, stating the following: "Choice Is Not A Usability Problem".

Ardent readers will notice that there is possibly a contradiction here. In this article I would like to explain why this is not really a contradiction, but rather a misunderstanding. To get us started, let's make a jump back in time (using Flux Capacitor technology):

The year is 2004. It's cold. You are alone. There is a house in the north (called "KDE"), and a house in the south ("GNOME"). Press "n" or "s".

> n

You have entered the house of KDE. It's a big house, full of obscure items. The sheer number of items is highly impressive, but you get confused. It is too much. What is your next step? Press "n" or "s".

> s

You have entered the house of GNOME. This house is neat, clean, but also kind of empty. There are very few things to play with. You get confused. What is your next step?

> I give up. User reboots into Windows.


The gist of this little analogy:

KDE was wrong. GNOME was wrong. Also - they both were right!


This is quite obviously another contradiction. Obviously this means that Mark is not quite right in the head! Well, you're possibly right on both accounts, but let me explain why it actually makes sense: The truth is somewhere in between.

KDE has historically been known for being "the nerd's desktop". Basically, we were so proud of having our own desktop that we quickly determined that giving everyone as much freedom as possible is ideal. After all, the competition (Windows) did not offer this. Developer A came along, going "Hey, I have this fancy idea. It's a bit weird, but let me show you!". Developer B was quick to reply: "Hell yeah, why not? After all this is our own desktop. We can make all of our dreams come true. Let's do it!"

GNOME has historically been known for being very sparse with options. They did this for a good reason: Someone smart realized that KDE was totally going overboard with options. Too much is too much. Let me show you a classical example:




Now let me show you an example of the Dolphin settings dialog:



Dolphin has won 2009's Akademy Award for "Best Application". The above screenshot demonstrates one of our reasons for choosing it: Peter Penz realized what generations of GUI developers (both in KDE and GNOME) got wrong: The true secret to getting your settings right is choosing the essential ones, while making good choices for defaults that don't need micro-options.

Unfortunately, this is not easy, and it separates the good GUI designer from the bad one. In fact making these choices is bloody damn hard, I kid you not. It requires a lot of thought, experience, and taste. But in the end, you, as a developer, are responsible for making these choices. Creating software is not about giving the user a LEGO blocks game. If options get too complex, the users might as well learn programming and do it all by themselves. That's because, if you think about it, choosing an option is programming: You make the program use one code path, or a different one. This is essentially the same as an "if() {}; else() {};" block wrapped in GUI sugar.

To sum it up:

Before adding an option, think hard about it. Could the same be achieved with a smarter algorithm? Often options are bad excuses for deciding between one bad implementation and another bad one. Find a good one!

Don't try to solve the problem by removing all options. Some options are very useful, and they are actually needed. Finding out which of these are needed is the developer's task. It's a hard task, but it can be done.

Consider asking professionals. We have a KDE Usability team, comprised of real experts on this topic. Among them is Celeste, a member of the KDE board. She knows what she's talking about, and she's generally very helpful. Don't be shy, ask them!

That's it for this time, I hope you will be able to get something useful out of this blog. Remember, it's not meant as bashing, but rather as useful advice, stemming from many years of experience with these things (we Amarok developers have made our good share of mistakes as well, there is little doubt about that).


Thanks for reading

What is const correctness?

It's a programming paradigm that helps writing correct code. In C++, const correctness comprises a set of different techniques, you can read up about them here. In this article however I only want to focus on one form of const correctness, that is object constness.

Why should I care about const correctness?

Because it increases type safety, makes your code more easy to understand, and it helps making your code correct. Const objects can be seen as invariants in mathematical terms, that is, objects that do not change, that do not vary.

An example in code:

const int myNumber = 41;

int result;



result = myNumber + 1;

KMessageBox::information( 0, "The meaning of life is: " + QString::number( result ) );

In this example, myNumber is a const object (an int is really a POD type, but let that not distract us). This indicates that I cannot change the object. And indeed, if I were to try that, the compiler would complain about it, which is a good thing. It helps preventing mistakes by accidentally changing this object later on.

Additionally, it helps readability, because anyone can clearly see that myNumber is not meant to be changed. So you see, writing that "const" before it is a little bit of work, but it has a big pay-off. I think it's worth it, so I try to use it always in my code.


PS: It's likely that somewhere in this article I made a slight mistake or a bad wording. With these things, you will always find a C++ expert who will point out something, because C++ is very pointoutable. So that might happen, but I'm fairly sure I got the gist right