Qt Kinetic: Declarative UI

Today, we (Qt Software) released a new user interface technology, called Declarative UI on Qt Labs. Declarative UI is part of the Qt Kinetic research project and is a completely new approach to programming with Qt: In contrast to imperative programming, declarative programming is a more natural and expressive way of creating software. The program logic is expressed in terms of what something should be, what it should look like and how it should behave, rather than described through control flow statements of creating, modifying and connecting objects.

So everything is totally new and leaves the old Qt behind? No! The Declarative UI builds on the core concepts in Qt and applies the ideas of declarative programming to user interface design. More information, including download links can be found in the announcement. This is also the place for feedback. Here is a video to make you drool a bit:

(YouTube link, Ogg Theora version)

Not convinced? The look at this:

(YouTube link, Ogg Theora version)

This dial example is implemented in 45 (!) lines of QML!

Note: No Fingers were harmed in making these screen casts</p.

KDE Dot News: Back To Where It Belongs

Following up on my last post, I wanted to give you a few more admin updates: Since a few weeks, KDE Dot News is back on its old server. Just like before the move to Drupal, after a short visit to Immanuel in Munich, it is hosted at Oregon State’s Open Source Labs (OSUOSL) along with some other Drupal-hosted sites.

I want to thank OSUOSL for their continuous and now even extended hosting of KDE sites. If you like the Dot, please consider a donation to those fine guys so they can keep us up and running. Thanks OSUOSL!

PS: I wanted to note that we moved away from Google Analytics to a private Piwik installation for the Dot due to understandable privacy concerns.

UserBase and TechBase: Achievements and Challenges

Finally I took the time to do some long-standing maintenance work on UserBase, our home for KDE users and enthusiasts and TechBase, our page for Admins and Developers, based on MediaWiki technology, for everyone to particilate

  • MediaWiki bumped to v14 (SVN)
  • True MultiHoming, lowers meantime between updates.
  • Case insensitive search for short words (i.e. ‘kde”) works
  • Search-as-you-type works
  • If a site search fails, you can now use other search engines to search the sites in a second pass.
  • TechBase and UserBase can now be added as search providers for e.g. FireFox and IE 8.
  • All wikis have been moved to a centralized unprivileged account on the server, so interested contributors can get shell access.
  • Finally: UserBase now allows normal logins next to OpenID logins

I changed away from exclusive OpenID logins minly because of two reasons: firstly, it seems there are just too many people who reject to the idea of a “unified login provider” (with the chance of their password leaking here and there once in a while). Secondly, not all OpenID providers seem to work perfectly. Interoperability is an important factor, but we are not there yet. Still, OpenID will remain an option for now. KDE support OpenID for a wide range of other sites such as the KDE Dot News or the KDE developers blogging platform.

But there is a lot of challenges ahead, from both the admin and the content side: That is why I renew my call for contributors and web developers to help UserBase and TechBase:

We need more solid i18n: Users should be able to dynamically switch the language of MediaWiki or possible be provisioned with the right language based on their browser settings or their IP (-> Geo IP). Also, the content should be delivered in a native language. Work in the MediaWiki community is on the way, but we need more dedicated people, as I am likely to have less and less time for these things due to my day job at Qt Software. If you are interested, please leave a comment.

Concerning the content, Lydia and the CWG are pushing for more content on UserBase, and TechBase needs more love from the content point of view. That is because although we do have a lot of information, it is not organized in a problem oriented way: Say for example you are an admin who wants to know how to pre set default settings: We do have details on the Kiosk Mode and other facilities, but most people will not know what a Kiosk Mode is. A FAQ style page (“How do I…”) would be helpful and provide more value to its users. If anyone is interested in solving this problem, please also leave a comment.

Qt Creator 1.1 Out in The Wild!

Fresh from the Qt Software site in Berlin, a crowd dubbed “the Berlin trolls” brings you: Qt Creator 1.1! The summary can be read in Eike’s release blog entry. But what are the highlights that you, the average ambitious amazing KDE developer should care about? The much improved CMake support for instance, or the support for Makefile-based projects that allow to use Creator as a code editor and code navigator on non-{qmake,cmake} projects. We also improved the gdb debugger integration and the window splitting behavior. The full ist of changes is available in the official changelog.

Meanwhile, Creator’s post 1.1 development is full steam ahead: If you are developing Qt or KDE on Windows, you will be pleased to find support for the Microsoft CDB debugger, which does not only work with MSVC binaries, but is also significantly faster than GDB (which you can only use on GCC-generated code anyway). Grab a new binary snapshot or even better, check out from the git repository. And if you are fed up with nmake only using one CPU on your multicore machine, speed up compilation with jom.

No matter if you are hacking on or with Creator: Enjoy!

Qt for S60: Get Garden!

Some news from my colleges of the Qt for S60 team: After the Qt 4.4 based Temple release only a few weeks ago, they busily hacked away to surprise us with Garden, the Qt 4.5 based release featuring native S60 styles, input method support and overall better integration and performance. Get details over at Jason Barrons blog at Qt labs, along with some hands-on video casts!

Qt Creator RC 1 Out For Your Testing Pleasures

With the awesome Qt Software guys in Oslo shipping a Release Candidate for Qt 4.5, we here at Qt Software Berlin couldn’t help but release a RC on our own. Presenting Qt Creator RC 1, a.k.a. 0.9.2 (Don’t ask, we just like the number). This version has seen quite some polishing, e.g.

  • Improved user interface with feedback option for your feedback
  • “Fake Vim” mode for VIM lovers
  • Improved Version Control Support (Perforce, Git and Subversion)

If you got curious you can get more details from our lovely team-member-in-Norwegian-exile Kavindra and the binaries from the Qt Creator page.

Userbase I18n And You

KDE UserBase needs you! UserBase is the wiki-driven site for user-related content, in case you have been living under a rock for the last year or so. So far, I am the technical contact for this site. I upgrade the software (which is Mediawiki) and add plugins and write some of the templates in accordance with the Team from the KDE Community working group, who has helped a lot to build up the contents of the site.

This worked as far as Mediawiki delivered all the features that we required. However there is one thing where no Wiki really works well, and Mediawiki, even though genereally best suited for our tasks, is particulary bad: Internationalization, or i18n for short. Some people are really dying to get localized versions going, so I really want to pursue this.

Whatever we pick as a solution should enable the follwing goals:

  • Up-to-date translation for a given language
  • A warning if the content is not up to date

Assets we have (depending on the activity of the translation team):

  • a lot of man power all the time
  • almost no man power most of the time

and we need to be realistic in assuming that “almost no man power most of the time” is true for a lot of languages, at least that’s what other wikis suffer from.

So far, there are two approaches to go about translations with a wiki:

1. Tie international sites to the original english content.
2. Have individual content for each language.

So far, UserBase implements Option 1, while lots of other Wiki sites, such as the OpenSUSE site or Wikipedia itself go for option number 2. The big disadvantage I see in number 2 is that, as long as most of the people that drive the development communicate in English, the English wiki will always be more up-to-date. If you look at projects like Wikipedia and OpenSUSE you will find that the most up-to-date versions are in fact the primary language (i.e. English), and while the others may have individual concepts, they usually lag behind severely.

This is why I am proposing to solve this in a more centralized fashion: One master article, lots of translations. That gives us two choices again, this time of more technical nature:

1. Set up an individual wiki per language

THis needs maintenance of even more Mediawiki installations, and I won’t be able to do this all on own. Problem is that we are particulary short on voluntary admins. It also means complete content disjointness, although Mediawiki sometimes helps with Interwiki links.

2. One Wiki for all languages.

This is probably the best approach to go about it, at least that’s my conclusion.

So far, we use URLs like


I would prefer an installation where we add one virtual host per language, all sharing a central wiki installation. Then
we could have something like this


This would link [[Adjusting plasma]], but without requiring a separate login or multiple setups for the contributors and thus conviniently link all language versions. To make that easier, we could add a “start translation” button that does this automatically.

As for the problem of aging translations, we could have a metric that kicks in after every edit and indicates how outdated the translation is, compared to the master page. If the translation contains more recent content, we could have that wrapped in special flags so other people knowing both languages get notified to “backport” the changes in the original version.

Which means one thing: We need someone with PHP and possibly also Mediawiki expirience to help us out with more functionality. Ideally, something that can be merged into Mediawiki proper.

I know that this is a fairly complex problem. I tried to outline it very briefly, but probably there are many open issues. Feel free to comment on them. Also, feel free to argument why one wiki is stupid and we should have multiple ones, while still solving the problems I pointed out above. Also, any other kind of ideas, preferably combined with some code or active contribution is very welcome.

If anyone from the Mediawiki community is reading this, I would appreciate a comment, too.

Why Current Linux-Preinstalls Pose Adoption Problems for Netbook Users

This christmas, Santa brought an Acer Aspire One (A110L) for my mother, a not so techy person. It even had a customized version of Linpus Linux on it featuring quite a pleasant, simple UI. It’s supposed to be simple and useful. And at first glance, that’s true: It comes with Firefox, OpenOffice, etc.

Unfortunately, there is also a downside. Why? Because it comes with Firefox, OpenOffice, etc… on Fedora Core 8, a quite old version of the Distribution. Firefox is on Version and no official update is available, leaving A110 users with known security issues and a product which is officially abandoned by the vendor. Same holds true for OpenOffice.org 2.3, the current Version is 3.0.

The Update System does not use YUM, it has propritary system that downloads XML descriptions, packages and shell scripts from a Taiwanese, overworked Server, with no (visible) signature validation (*yikes*).1)

So I wanted to install Skype, since that’s what my family uses to do voice and video chatting. The built-in messanger also has no support for Jabber. So I wanted to install skype and PSI instead of the built-in messanger. Both turned out to require advanced Linux-Knowledge (installing RPMs manually in case of Skype) and some google searching (becoming root, add items into the menu). Some choices, like the choice of language can only be done via
the GUI initially. Later on, one needs to find a script that sets environment variables and reboot the system.

So where is the trouble? The extra step via Linpus. While it seems like the ideal OS (Startup time of about 4 seconds, easy launcher interface), it

  • Keeps the users from secure upgrades to decent versions. Even worse: It keeps the users from even customizing their Netbooks just a little bit. With the Windows XP variant, installing Skype is just a Download and a Mouse click away. That’s why I find a lot of people moving on to XP right away or buying the XP version in the first place. The hypothesis that netbook users accept their devices just the way they are is a myth.
  • Keeps the average user from installing new Software (keep in mind the target audience!).
  • Woeks around the underlying distributions update infrastructure.

Not sure if Ubuntu’s Netbook spins are the answers, but I will definitely give them a try on an external SSD medium.

1) I admit that this is not the central point here, but since I’m at 25c3 and Dan Kaminsky has just stressed how many update systems suck because they lack any kind of validation about the blob they are about to download and run as root, I felt like pointing it out.

PS: Dear Lazyweb: Does anyone have expiriences with other Netbook Vendors? I am under the impression that the Eee PC preinstallation suffers from similar problems.

On Icons and Labels

To be frank: I think that the Kubuntu’s switch to “Text aside icons” (as discussed by Seele) was a mistake. The reasons for that are best explained by an example:

Here, only one of three actions are visible in the tool bar, rendering it pretty useless. But let’s revisit what we had as the default in KDE 3 before we used “Text below icons”:

Now, “Text below icons” is a bad idea, because it wastes vertical space, which we are already short of (Plasma panels, menu bar, window decoration). Given the emerging 16:9 ratio monitors, this sounds like a call for “Text aside icons”, the new Kubuntu default:

During the quite vivid and productive discussions on Seele’s blog, some people proposed to show the text only for special actions (mockup as posted there). This does not only allow to easily spot the most important of the actions (keep in mind that all actions in the toolbar should be kind of important, otherwise they shouldn’t be there), but also eases hitting the actions tool button.

Actually, this idea has gone through my mind quite often and our friends over at the competition used this for ages, albeit for Evolution only. Instead of going for such a solution, KDE has struggled for years searching for the right defaults and discussed about screen resolutions.

The actual reason for this was mostly of technical nature: QToolBar couldn’t change the tool button style property for specific actions in Qt 3.x, and the almighty XMLGUI layer used by KDE thus had no such option either. Instead, one everyone got to pick his poison (no description, or space wasting ones).

Attentive readers will have noticed my deliberate use of the past tense in the paragraphs above. This is because with Qt 4, it is possible to do just what I said was missing: Adding actions with an individual Qt::ToolBarStyle. So without further ado, here is my (code-backed) mockup:

The secret is to add those actions that should get a text aside the icon like this:

    QToolBar *bar = mw.addToolBar(QObject::tr("Actions"));
    bar->setIconSize(QSize(22, 22));

    QToolButton *tb = new QToolButton;
    tb->setDefaultAction(new QAction(QIcon(":/icons/mail-message-new.png"),
                                     QObject::tr("New Message"), tb));

This is officially documented behavior. Quoting the Qt docs on QToolBar::addWidget():

If you add a QToolButton with this method, the tools bar’s Qt::ToolButtonStyle will not be respected.

Now it shouldn’t be too hard to add suppport this idiom to XMLGUI, by adding a flag for “important” actions. That said, XMLGUI is a quite complicated and fragile matter. However, I will take a look at this soon to see if it can be implemented in a clean way without patching Qt.

PS: I think this is one example where less could actually be more in KDE. If we get this right, there is no need for choosing an icon label alignment at all.