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 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.

Time To Become a Qt Engineer!

Or should I say: “time to become a real Troll”? Yepp, the deadline for my thesis, which I’m currently doing at Qt Software (formally known as Trolltech) is rapidly approaching. So I will now apply for “full membership”. That is, for a job at Qt Software Berlin. And so can you! Nokia’s Qt Software division is looking for even more developers in Berlin, Germany. This is especially good news for those who hesitated to join because Oslo was too far in the north. Berlin is a great city to live in. Take the opportunity to work with these fine people!1)

And if Berlin really isn’t for you, try PSO in Brisbane, Australia or simply search for “Qt” at the Nokia Career Portal to find a lot more Qt-related job opportunities at Nokia around the world. Apply now and send in your resume! Nokia is waiting for you.

1) Not actual people, just photographic representation. Expect even better fidelity when meeting them during your interview.

KOVpn: A helpful little tool returns

Disclaimer: No KDE 4.1 hype here. This is for the real retro folks (aka KDE 3.x users).

KOVpn is a simple, yet helpful tool to connect to private networks using the OpenVPN software. It was nice, but needed some more improvements (indicated by its version number). Unfortunately, the last maintainer vanished along with the project page and the download files. However, I was able to get hold of the latest stable release via our University sysadmin (and KDE veteran!) Chris Neerfeld. Since OpenVPN is used in my uni to gain WiFi access, I moved the tool into a trac environment at our labs project hosting service.

With the help of another lab member, Jochen Wierum, I also managed to get out packages for OpenSUSE, Debian and Kubuntu via the (excellent!) OpenSUSE Build Service. Also, thanks to a fix Jochen contributed, the latest release also works on 64 bit distros.

So what now? This is a KDE 3 app, so its days are clearly counted. Yet it will hopefully help, since KDE 3.5 will probably be around for quite some time. Currently I am considering a Qt 4 port, if my time permits. But actually, it is really NetworkManager who should become smart enough to handle all kinds of OpenVPN setup, instead of the rather limited options it offers nowadays. Let’s see what the future brings. In the meanwhile, enjoy KOVpn!

PS: Be warned The setup currently involves manual setup of OpenVPN, but using it afterwards is a real joy, compared to using the commandline or weired custom scripts

PPS: Dear Lazyweb: Do you know how work on NetworkManager is progressing wrt OpenVPN integration?