In case you wondered why I - again - didn’t make it to aKademy, here you go: Our daughter Helen was born on June 16. Here’s the obligatory screenshot:

She looks like an angel, and she totally is one. So far we had a fantastic time, and it’s getting better every day. Getting a daughter is simply awesome. Think of it as having your birthday at the same day you win the lottery and KDE 4 is released, and you won’t even get close.

Looking in her eyes I can’t say I regret not having been to Glasgow, but reading all the postings about the conference I’m really looking forward to participating again next year.

The problem in brief: Trolltech invented signals & slots, Boost implemented the concept using plain templates, and ironically you couldn’t easily combine both libraries because of a relatively simple name clash. Trolltech used macro keywords and Boost loved our naming so much that they picked the same terms => clash. Off topic, I like that they took our naming, it’s a bit of a pity recent implementations done by other parties call the very same concept events and delegates.

Anyway, with “CONFIG += no_keywords” we have solved the name clash in Qt 4.1, released in December 2005.

Scott Collins now let me know, that the May update of the Boost libraries has an updated Boost.Signals FAQ with respect to Qt that describes the technique. Have a look at http://boost.org/doc/html/signals/s04.html. It explains how to use Boost signals & slots in Qt applications, and also references Scott’s own article, “A Deeper Look at Signals and Slots”.

Update Monday, 30 June 2008: The links appear to be dead by now. No alternative links known to me, sorry, but way back can help: http://web.archive.org/web/20070703100120/http://scottcollins.net/articles/a-deeper-look-at-signals-and-slots.html

If you followed labs.trolltech.com, you’ve seen a new addition: QLALR. It’s a LALR(1) parser generator, created by Roberto Raggi of Qt Designer and KDevelop fame. Originally developed as Creative Friday project, it quickly got used in various projects within Trolltech. One example is the new script engine - no surprise, Roberto also had his fingers in this one - but also the new XML stream-reader. Writing a fast bottom-up XML parser was a welcome challenge, and with the flexibility of QLALR actually an enjoyable ride.

QLALR is not very well documented, but if you do understand LALR(1) and have used tools like yacc before, you should get along well with the examples. Admittingly, knowing Roberto has also helped. For the lexer, you can use QLALR with whatever scanner generator you like, or you handcraft it. I’ve also seen a few scanner generators in Trolltech, maybe one will make it on labs some day.

Btw, the last link demonstrates another new feature of our web site: we finally have the snapshot documentation online, regenerated from the source code repository daily.

In case you are still undecided whether or not you should visit the Linux Tag 2007, from May 30 to June 2, 2007 we’ll have a small booth there, too. It will be staffed by Trolltech engineers from Berlin and Munich.

To me that’s good news. LinuxTag was always the best Linux show out there, and the only show where free software projects and commercial entities could present on almost equal terms. In the previous years we didn’t make it, but this year’s prime location at the Berlin Expo Center under the Funkturm made it simply irresistible for us.

Looking forward to seeing you there!

Snapshot users have seen them already: with QXmlStreamReader and QXmlStreamWriter, Qt 4.3 will feature two new classes for reading and writing XML.

QXmlStreamReader is a faster and more convenient replacement for Qt’s own SAX parser, and in some cases also for applications that would previously use a DOM tree.

The basic concept of a stream reader is to report an XML document as a stream of tokens, similar to SAX. The main difference between QXmlStreamReader and SAX is how these XML tokens are reported. With SAX, the application must provide handlers that receive so-called XML events from the parser at the parser’s convenience. With QXmlStreamReader, the application code itself drives the loop and pulls tokens from the reader one after another as it needs them. This is done by calling readNext(), which makes the reader read from the input stream until it has completed a new token, and then returns its tokenType(). A set of convenient functions like isStartElement() or text() then allows to examine this token, and to obtain information about what has been read. The big advantage of the pulling approach is the possibility to build recursive decent parsers, meaning you can split your XML parsing code easily into different methods or classes. This makes it easy to keep track of the application’s own state when parsing XML.

The streaming concept is not new, it’s what other APIs use as well, e.g. Java’s StAX or libxml’s TextReader approach. In fact, it’s pretty much the straight-forward and intuitive approach to reading tokens. The weird thing was SAX and honestly I can’t remember what had driven us to implement SAX in Qt in the first place, other than lack of time to design something better. We had it on the list for a long time, now we finally got around doing it.

The streambookmarks example in the Qt snapshots shows how to use both classes. Here’s the typical main loop:

 QXmlStreamReader xml;
  ...
  while (!xml.atEnd()) {
        xml.readNext();
        ... // do processing
  }
  if (xml.error()) {
        ... // do error handling
  }

The parser is well-formed and also supports incremental parsing. And it’s a lot faster than Qt’s SAX and DOM implementations. If things work out well, we might base the SAX parser in future Qt versions on QXmlStreamReader, which would make our SAX implementation both faster and more compliant. But even then, QXmlStreamReader is the fastest and most convenient way to read XML data in Qt.

So, we are making some progress with our expansion into Germany. Here are some pictures of the office building we currently favor. It’s a rather old building from the former Academy of Sciences of the GDR, but beautifully renewed. Nice address, too: Albert-Einstein-Strasse, Berlin. The guy on the right hand side, standing smiling in the entrance hall, is me. But don’t worry, Trolls don’t normally wear suits, and German Trolls won’t neither.

Here you find a picture of the building from above. It’s the tall gray building in the middle, with the egg-shaped entrance hall in front of it. It’s the tallest building in the area, which guarantees a great view in all directions. Getting interested? Here are some images of the entire area. While the Adlershof technology park is a bit outside Berlin, downtown Berlin is only a few minutes away by train. Many people working on the park do indeed live downtown.

But offices don’t write code, developers do. If you look at www.trolltech.com, you will find that we are indeed looking for good software engineers, for Berlin and for the other office locations. If you enjoy writing Qt or KDE applications, and always wanted to be able to change Qt without having to send patches to qt-bugs, then this is your chance. The “I don’t want to relocate to Norway”-argument doesn’t count anymore. And the “I don’t want to relocate to Berlin”-argument doesn’t count either, because you can most certainly relocate to Norway! I’ve heard concerns from some developers that they didn’t feel good enough to apply. That’s bogus. For one, you can always apply, it costs nothing. For the other, if you write Qt applications or KDE libraries, you are very likely good enough. Qt’s quality stems from the fact that we work together well, not that we are all ueber-programmers.

If you want to give it a thought and have some questions prior to sending in an application, please talk to me or your nearest Troll on IRC. Looking forward to hearing from you - soon!

The beautiful facade	The office that could be yours
The entrance hall

The community reactions to the release of 4.1 were quite encouraging. If you followed some of the discussions, e.g. on http://osnews.com/comment.php?news_id=13042 , you have probably noticed that even the most verbal critics are finally running out of arguments. Basically the only complaint that’s left is that Qt - fasten your seat belts - adds introspection to C++. And it does this by - fasten your seat belts tighter - defining three [sic!] macros: Q_SIGNALS, Q_SLOTS, and Q_EMIT (or for the more pragmatics among us: signals, slots, and emit). Muahuahua, evil Trolls, how dare we extending C/C++ for the benefit of programming? Are we too stupid to realize that C++ should not have introspection, that those who want introspection should use Java or a scripting language, or at the very least code their meta code by hand?

Ironically enough the complaint doesn’t come from C or C++ programmers, those are quite used to macros. The complaint comes from people that prefer other languages, and consequently they dislike Qt for making the life of C++ programmers easier. We wrote Qt, we know it is not a “pure” C++ framework, just like C++ is not a “pure” language. Qt makes use of the C-subset of C++, including the preprocessor. And it makes very good use of it. What made C++ the most successful programming language on the planet is its pragmatic design, and its compatibility with C. It’s a meta language, a language powerful enough to be extended to something as beautiful and easy to work with as Qt.

Seriously, we dislike having to use macros just as much as any other C++ programmers. I wish there was a standard C++ preprocessor that fit better into the language than cpp does, and that understood namespaces. However, if three macros are a big problem for you to trade against a wealth of features, than I really envy you: The rest of the world you live in must be really perfect.

The other thing that’s funny about the whole debate is the fact that Qt - like any other successful real-world C/C++ framework that supports different platforms and compilers - defines many more macros than that. Prominent ones are Q_OBJECT, QT_VERSION, Q_OS_UNIX, Q_WS_X11, Q_DECL_DEPRECATED, Q_DECL_EXPORT, and watch guards around each headerfile like QOBJECT_H, QWIDGET_H, QPUSHBUTTON_H, and so on.

And for those that wonder what real abuse of macros is, have a look at http://cvsweb.xfree86.org/cvsweb/xc/include/X.h?rev=1.1.1.2

Can’t wait until 4.2, and 4.3. There will come the point were the last ones not to use Qt will realize that they have bet on the wrong horse. Muahuahua.

The recent discussions on KDE versus other Linux desktops - accidentally started by KDE-user Linus Torvalds - showed an interesting new development in the eternal debate. First of all it didn’t come as a surprise that Linus uses KDE, after all Fritz Elfert made it very clear back in 1996 that KDE stands for “Kernel-Hackers’ Desktop Environment”, when Kalle and the German IT press still pushed “Kalle Dalheimer Experience”. What came as a surprise was that the old GUI versus command line discussion against KDE, that later turned into a Free Software versus Lesser Free Software dispute, now changed shape again. The fashion of the day is: complicated power user environment versus user-friendly simplicity. And as opposed to 1997, when a vocal minority avoided us for our focus on end-users and simplicity, and went to other projects for more “Unix-guru friendliness”, themes, and features like window manager independence, they now want to deny us exactly this: simplicity and user-friendliness. Now, how bold is this? KDE’s mission has always been “ease of use, contemporary functionality, and outstanding graphical design” (kde.org), and we have succeeded delivering exactly this for the past decade. We took GNU/Linux out of the system administrator’s corner and put it on millions of desktops, an achievement that nobody can take away from us.

Why am I writing this, to an audience on planetkde that mainly consists of KDE users and supporters? Well, when you follow the debate, you can notice that even KDE’s supporters show willingness to follow the opponents’ twisted claim about KDE being overly complex. Instead of rejecting those as ridiculous, they rather argue for the necessity of a rich feature set. Yes, KDE has a rich feature set, and yes, that’s what is required for contemporary functionality. But hello, that doesn’t mean that it’s hard to use. Let’s not swallow this crap anymore! Let them repeat it as often as they want to repeat it, and simply reject it as what it is: the best they can do, but utterly wrong.

To be even more explicit: It’s a fairy tale that end users will decide against KDE when given the choice, and it’s a fairy tale that KDE is more difficult to use than any of the alternatives. The simplest possible desktop has one big push button to turn the computer off, everything else is a tradeoff between simplicity and functionality. KDE’s beauty is that it enables ordinary people and computer freaks alike to use their computers; it’s what makes it the better desktop. Everyone who has installed it for friends and family can report that even casual computer users don’t have problems with it. Quite the opposite: Users do amazing things with it. Especially those coming from Windows feel they can do so much more with a KDE workstation, and they do. They also seem to have significantly less trouble navigating the control center than self-proclaimed usability experts on web discussion sites.

No software is bug free, or free of flaws. We - the KDE developers - happily admit that usability is a process, a data-driven process. And that’s what we work on. Many of us also admit that parts of KDE feel a bit too crowed for our taste, that our naming conventions for applications have room for improvements, or that our reliance on context menus is suboptimal. But make no mistake: Even with those flaws, KDE is an exquisite choice on the desktop, and in our opinion the only real choice on GNU/Linux.

There are end-users out there that made the switch to GNU/Linux but don’t use KDE yet, that’s something we have to accept. Millions of investment capital and corporate backing do show some effect, at least short term. However, I believe that the number of those who objectively evaluated several desktops and decided against KDE is certainly very low relative to those who never had a chance to try KDE. It likely didn’t come as the default on the Linux distribution they installed, or it wasn’t described in the book they bought, or wasn’t the local Unix guru’s recommendation. There are many cases where users simply are never exposed to KDE.

KDE is all about ease of use, contemporary functionality, and outstanding graphical design, and we make it better and better with every release, in all three aspects.

Merry Christmas everybody, looking very much forward to 2006: another year of the Linux desktop.

Lately I got involved in a longish discussion on IRC around application names and how to present them. A prominent spot is of course the K-Menu, but there are others: the title and task bar, the documentation, the about box, and various context menus (as in “Open with ….”).

At some point in time, KDE used to only show application names, and some generic names for operations like “Find Files”, “Run Command”, etc. When we got more and more applications, those menus became very cryptic. This has to do with the way we picked application names. Essentially we created executable names by abbreviating what the program was supposed to do, and then added the k prefix. Then we took the executable name, upper-cased the first letter of every part, and so deducted the application name. A typical but not uncommon example is “KRegExpEditor”.

Since users were not too comfortable with names that looked like C++ classes, we added the concept of a generic name, in our UI referred to as description. For the K-Menu today, we offer the user three choices: “Name”, “Name (Description)”, and “Description (Name)”.

To pick a real example, you can choose between “KWifiManager”, “KWifiManager (Wireless Lan Manager)”, or “Wireless Lan Manager (KWifiManager)”.

SuSE goes further. They have a menu system that shows only the description as long as only one application of its kind is installed. The moment you install a second application, this description turns into a submenu which contains the “Name (Description)” entry shown before.

Example: normally you have an entry “Chat” under “Internet”. If you click on it, it will run kopete. If you don’t like kopete as IRC client, you install ksirc as well. This turns “Chat” into a submenu with two entries “IRC client (KSirc)” and “Instant Messenger (Kopete)”.

So what’s the problem?

I see two problems with our current approach. First, the menus are not very readable. Second, the generic names prevent us from picking really good descriptive names. Have a look at the following two screenshots to see what I mean:

http://shots.osdir.com/slideshows/slideshow.php?release=234&slide=5

http://shots.osdir.com/slideshows/slideshow.php?release=286&slide=29

Generic names are not a solution, they are are a hack around bad application names. Ironically they also make good looking, descriptive names look bad, because those are likely to duplicate elements of the generic name, thus when presented together with the generic name, the menu item looks even worse. And when you launch an application with the generic name only, how do you recognize the window in the taskbar (it shows the name), or talk about the application, or look it up in the documentation? And when you install a different set of applications (e.g. because you want to try out the other desktop), you have several applications with the same name. Under Multimedia/CD/DVD Burning you will get two applications that claim to do the job, none of which is marked to be the KDE application. The only hint is the “(k3b)” suffix.

For those interested in further reading, here’s a discussion on the the use of generic names from last year

http://www.gnome.org/~clarkbw/blog/GNOME/Fear_and_Loathing_in__desktop

and an interesting response dubbed “Generic Names Considered Harmful”

http://blogs.gnome.org/view/shaunm/2004/7

So what’s the solution?

The initial problem was bad names. We tried to solve it by introducing generic names that potentially apply to many applications. What if we fix the root of the evil instead and give our applications good descriptive names? This is something all application maintainers have to contribute to, we can’t just have someone going through the repository and renaming things.

What’s a good descriptive name? A combination of the name and the function of an application. Why is this supposed to be better than “Description (Name)”? Because it will be shown and used everywhere where the application is referred to, it’s better readable (no parentheses), and it avoids the duplication between description and name that we see so often nowadays.

Here are some examples, they might not be perfect, but they can give you an idea:

Web Browser (Konqueror) => Konqueror Web Browser
PalmPilot Tool (KPilot) => KDE Palm Pilot Tool
Popup Notes (KNotes) => KDE Popup Notes
HTML Image Map Editor (KImageMapEditor) => KDE Image Map Editor
IRC Client (KSirc) => KDE IRC Client
Instant Messenger (Kopete) => Kopete Instant Messenger
KDevelop => KDevelop IDE
CVS Fontend (Cervisia) => Cervisia CVS Frontend
Personal Information Manager (Kontact) => Kontact Personal Information Suite
CD/DVD Burning (K3b) => K3B CD/DVD Burning
Sound Mixer (KMix) => KDE Sound Mixer

and so on.

We would end up with many KDE-prefixed names, and that’s OK. If you show those applications inside Gnome or XFCE, you probably want to see what is a KDE application and what is not. In KDE itself, we don’t have to show the KDE prefix, we could just drop it, or indicate it with an icon or the kind of icon that the application gets. If we happen to have more than one application that fights for the same “KDE Foo” name, we will have means to solve that conflict, like we solve other conflicts in the KDE community. Judging from going briefly through the list of applications we have today, there won’t be too many conflicts.

Summary

Please, let us get rid of parentheses in menus, and please give your KDE applications descriptive names.

There has been a lot of focus on the desktop lately, and how the desktop should evolve. Rephrasing the questions: what can/should/might KDE 4 become? There are many good ideas out there, some of which I hope will get implemented. But there’s also things I miss in the current debate, things that deal with the fundamentals of desktop computing. What a splendid opportunity to write my first blog entry, I thought, and so I did.

Some background for this article: I had the opportunity to observe an untrained desktop computer user doing real work using KDE 3.4 and Open Office. I also had the possibility to make suggestions to the workflow. The task was straight forward: Someone was sending dozens of doc files as e-mail attachment, and expected translations back. As easy the task sounds, I was surprised about the challenges that desktop computer users do face. I believe I learned valuable lessons from combining that experience with prior observations, and I would like to share my thoughts with you. In case you are a KDE developer who hasn’t yet had a chance to spend some time watching non-techie users using computers, please try to. It’s worth it, and it’s fun, no matter what desktop system they are using, KDE, Windows or Mac OS X. Watching real users doing real work on real computers is likely the best way to gain the experience necessary to create the next generation desktop system. I don’t want to read a manual before using a mobile phone, or operating a DVD player, and I don’t have to. Sending an email, receiving some files, translating them and sending them back is in the same league of complexity, and it shouldn’t require extensive training, or the need to understand how the system works under the hood.

Window management

Nobody likes to do window management. Wirth was right, although few people believed him when he designed Oberon. Users seem to go a long way to avoid having to adjust a windows position or size manually. This isn’t just untrained users, this is everybody. You can observe the same patterns on hackers everywhere. They sit in front of 20″ screens staring at a 1600×1200 background image and then typing commands in an 80×25 text window with a tiny font, having to scroll up and down all the time to read the output. It takes significant pain before someone actually uses the mouse to maximize the window vertically, or puts it to a more central spot on the screen. The same happens with other users. They go a long way scrolling around in a tiny file manager window before they might decide to make the window larger.

Lesson learned: the ideal window manager is the one that you don’t use at all. This needs support from the applications. Applications don’t normally start up with a sane size. Maximizing isn’t always the solution, especially because the most often used applications don’t work very well when being maximized, among them web browsers, consoles, plain text editors (think an email composer). Every application that does line breaks based on the window width has this problem.

Another problem with window management today are secondary windows, also called dialogs. In KDE, we try hard to bind those closer to the application main window. For example, a dialog doesn’t have its own entry in the taskbar; when you raise a task, its dialogs are kept above the application main window; when you minimize a task, you also minimize its dialogs. But the connection isn’t perfect. While dialogs are placed in the middle of their main windows, they don’t adjust position and size when you resize or move the main window. And when you try to activate a modally shadowed main window, the only visual clue you get is that nothing happens. Ideally, dialogs and other stand-alone secondary toplevel windows should go away for standard end-user applications. Having things like Apple’s sheets and drawers that naturally extend and modify the main window itself feels more natural, more elegant and avoids confusion.

Configurability

What I said about window management also applies to configuration. Nobody likes to configure anything. Sometimes people like to customize something, but that’s different. Customization means giving the computer a personal touch, with colors, images, or sounds. Changing the computer’s behaviour is entirely different. Configurability is costly, because it’s code that must be maintained, and it’s getting harder and harder to test all combinations. Even KDE’s own file dialog doesn’t work properly with all the 6 different completion modes that KDE offers for combo boxes. In DropDownList mode, you can no longer navigate with the keyboard to sub directories. Likely an easy bug to fix, but that’s not the point. The point is that with all that configurability, even a community that diverse and large as KDE’s cannot ensure basic functionality working in all modes. KDE 4 is our chance to get rid of all that clutter, I hope we make use of it. “Those who write the code, decide” is a good rule, but it only works if there is a strong maintainer or group of maintainers with a clear and aligned vision. Many parts of the KDE had this, others didn’t. And that’s where we see the issues today.

File manager

Konqueror today is a swiss army knife. That’s cool, people like swiss army knifes. I used to have one, too, and I loved the engineering behind it. Putting so much functionality in one single device is admirable. But I never used it unless I absolutely had to. At the campfire I had to, and I was happy to have it. At home or in my kitchen, I don’t have to. Instead I use whatever knife, screwdriver, or other tool that fits best for the job.

A document manager is not a webbrowser is not a text editor is not an image viewer is not a console is not a trash bin. Profiles are a way around it, but not the solution. Profiles are just like opened swiss army knifes. It’s like buying 4 swiss army knifes and having one lying around as a knife, one as a saw, one as a screwdriver, and one as scissors. Whatever you do to them, they are still swiss army knifes. They can magically convert into something else, and they will if you do something to them.

I get the feeling we do embedding and morphing not because its useful, but because we can. And we are ignoring its downsides. And the biggest downside in my opinion is that it takes mindshare away from dedicated applications which would do the job better.

A little example: you have a browser window that covers 40% of your screen, it contains pictures that you have taken over the weekend. You want to show them to someone else. In KDE today you would probably find an empty spot on the icon view, and then select Preview_In/Photobook. Or you are one of the few chosen ones that know the icon on the toolbar. What you then get is a fairly good embedded image viewer, but it’s still only an embedded image viewer. And it’s only using 40% of your screen. You can then maximize the window, or - if you are an expert power user - select Settings/Full_Screen_Mode. I found it after looking under “Window” and “View” first, by accident. But even then you don’t see any image in full size, you see Konqueror in full size. You still see the side bar, the navigation bar, and a tool bar. Here’s how it should be (and surprisingly this is also how Windows Vista works): Having images in folder results in little button that says “View slideshow”. You click it, you get a full screen viewer that shows your images. Simply, intuitive, what you want, what you expect, and no window management action required.

Konqueror’s future is being a dedicated web browser. What KDE needs in addition is a dedicated document manager. Great preview capabilities, yes, embedding, no. Konqueror is not a document manager, it’s a generic tree structure browser. And if all you have is a tree structure, everything looks like a kio-slave. Our trash bin in KDE 3.4 is a nice example for that rule: it’s a full blown browser window that uses the trash:// protocol. And the one main operation that you want to do with a trash bin (emptying it) is only available in the context menu of the icon, or the free space in between the items. Who is supposed to find that?!

I’ve been discussing design ideas with Zack and Simon, and hopefully we are able to present a prototype of how a modern file manager for KDE 4 could look like. And if that’s done properly, the desktop itself should probably be such a view. Today the desktop is a set of links that show huge tooltips with interesting contents like “myComputer.desktop is a Desktop Config File that is 170B large, owned by ettrich - users with -rw-r-r– and points to media://”. Thanks for letting me know…

A nifty feature I’d like to see in a file manager is that it shows me when I’m visiting a document currently. And while being at it, single click for opening documents is wrong. Initially I thought it was a good idea, too, but after having tried to use it for a while, I changed my mind. Unless I’m the only one who constantly starts applications by accident when I want to move files around, or delete them.

I’m looking forward to aKademy, to heated discussions, and even hotter coding sessions!