As we’re having a board meeting in the KDE e.V. office in Berlin, we thought we’d take a photo for posterity.

Left to Right: Cornelius Schumacher (President), Frank Karlitschek Celeste Lyn Paul, Sebastian Kügler, Adriaan de Groot

Claudia Rauch, KDE e.V.’s business manager took the photo. Normally, I’m not the overdressed one (but I do wear my KDE 4.0 Release Event t-shirt underneath. On the photo, it’s not very well visible, but Celeste does have part of her hair blue.

This morning, while having my usual Cafe Latte (albeit this time in Berlin instead of at home sweet home in Nijmegen), I read about the Trinity project, which is an effort to revive KDE 3. I think this project nicely shows the advantages of Free Software. While the vast majority of KDE contributors agrees that KDE 3 is a dead end, technologically, these two guys (according to the somewhat sparse information on the website) are trying to continue to support and feature development on KDE3. Now I see a couple of real challenges for this project:

• Maintainance – KDE 3 is a large codebase. You need a good amount of people with domain knowledge of many different areas to effectively maintain a project like KDE. I see some of the first roadmap tasks for Trinity are updating the build system to deal with all the updated developer tools (e.g. newer autotools versions).
• Upstream Support – Official support for Qt3 ended on July, 1st 2007. nearly three years ago. Now this is not necessarily a problem (as Qt, too is Free Software), but it puts additional stress on the maintainance team — you have to provide support for Qt as well, not only KDE. This is also true for many other upstream components
• Community Support – KDE has many applications, and their developers take conscious decisions wether or not to support a specific version. Moreover, developers take great pride in their creations. Patches made to those components (even if it’s just maintainance) should be reviewed by their developers (who also happen to know the codebase best, have domain knowledge, and so on). Now the resources of these subprojects are also limited, and many decided to effectively end of life the support for their KDE 3 versions and fully concentrate on the KDE 4 version.
• Interoperability – In KDE 4, we introduced a couple of new technologies, D-Bus as our inter-process-communication mechanism, and the FreeDesktop icon naming scheme for Oxygen, KDE4′s artwork pillar. This was (and is) not possible with KDE3, and is actually only the tip of the iceberg of many improvements that have gone into KDE4, and which cannot be taken advantage of by programs based on KDE 3.
• Testing & QA – While the whole KDE project switched to KDE 4, we realised that releasing KDE 3 would be a lot harder in the future, since we heavily rely on the community testing the code before releases. This assures that the code is of sufficient quality and actually works. This process is not quite trivial, it needs testing, but also reviewing of changes that go into the codebase. For reviewing code you need familiarity with the APIs used by it, the actual codebase that’s being changed, and on top of that domain knowledge of the area your program is used in (for example if you’re writing a mail client, you should know mail protocols, and so on.) Again, you need a larger team to assure sufficient quality of the code you release.

For the above reasons, the KDE community has decided to not do releases of KDE 3 anymore. Technologically, it’s a dead end since many architectural, structural and environmental aspects of KDE 3 couldn’t be solved in KDE 3. If we just kept releasing KDE 3, we wouldn’t be able to assure sufficient quality and enough support so people wouldn’t be left out in the rain. Or put in other words, it would give KDE a bad name. The KDE3 branch in our SVN source code repository remains frozen for new features, bugfix patches are allowed but make very little sense, since there’s no plan to release new versions of KDE 3.x. That’s why the Trinity developers are using a work branch.

Those are challenges the Trinity team is facing now. Some of them can be solved by pouring enough manpower, tender love and care into it. Others aren’t easily solvable (think IPC) within KDE 3. Whether or not the Trinity team will succeed in maintaining and developing KDE 3 remains to be seen, but it’s certainly not an easy task. Then again, easy tasks are boring, and the Trinity team is validating the Free Software development and licensing model. In any event, the KDE community supports the efforts (for example by offering infrastructure in the form of source code repositories), and would like to see Trinity as another blooming subproject inside the KDE community.

Since there were quite some changes in the Network Management machinery in KDE Plasma over the last days, I thought I’d sum them up here, as to update the brave that already use the as of now unreleased Plasmoid.

• Plugin name changed – We’ve changed the name of the networkmanagement plasmoid plugin to from "networkmanagement" to "org.kde.networkmanagement" in order to avoid possible future naming conflicts. This means that you might need to re-add the NM widget to your notification area (do that using the config dialog and checking the Network Management plasmoid)
• SVN switched from KNM to the Plasma Widget – I’ve just committed a set of changes that enable the NM Plasma widget by default, this means no more pesky manual loading of the kded service module. It also means that the autostart file for knetworkmanager is not installed anymore, since we’re using the Plasmoid now. If you’re compiling from SVN trunk, you can use cmake -DINSTALL_KNM_AUTOSTART=ON to get it back. Make sure you prevent the kded module from autoloading (or just unload it), if you want to go with knm (Alternatively, tell us why you prefer knm above the Plasmoid and we’ll try to fix it).
• New artwork – As you can see, we have been working hard on improving the visuals of the NM widget. While it’s not perfect yet, it’s definitely getting better in terms of consistency, layout and overall visual appearance. With a bit of help from notmart, the Plasma NM widget in trunk now uses artwork from the Air theme, which is installed by kdebase. For backwards compatibility (I like all those people testing on 4.4!), we’ve chosen to install the artwork for "older" versions (last week and before), but we might be lax updating it (as it happens with copies of files in source trees).
• New souls – Over the past days, two new hackers have started sending patches for our network management machinery. One is Lamarque Vieira Souza, who has been working on modemmanager integration, that stuff that gets you on the Internet when relying on 3G, HDSPA and the like. The other one is Andreas Demmer, who has been continously testing the Plasmoid over the last months, already contributed some artwork, and today finally got his SVN account and started committing fixes. Welcome, guys!
• Many others – There were also many other changes, some fixing bugs, others small layout improvments, those will keep coming.

As you can see, we’re on the home stretch for a first release, fixing up all kinds of small issues, testing, reviewing things. After that, we’ll move the NM Plasmoid to KDE Extragear and release it from there. Before or with 4.5. Promise.

Last night was the last night of Tokamak 4, our semi-annual Plasma sprint for me, this morning I boarded a train to Düsseldorf (Germany), where I’m staying for another two nights with K.

Tokamak 4 was again a total blast. The Suse/Novell offices in Nürnberg were the perfect place to get a (for a sprint, anyways) rather large group together to hack day and night. I think I averaged about 6 hours of sleep, not bad. On the other hand, I didn’t get as much done as I wanted, but got a number of other things to take care of, so that’s OK.

You’re probably most interested in the progress of the network management Plasma widget, so I’ll explain a bit what we’ve been working on. We is Will Stephenson and Alex Naumov from openSUSE, Aurelien Gateau from Kubuntu (who took part remotely), Martin Zilz of the Oxygen team and me. The goal of the network management plasmoid is three-fold: it should be very easy to get your network set up, it should be technically robust and flexible, and it should also look good doing all that. We started of with fixing some bugs, Will got a bug in our DBus service fixed which would put bogus connection items on the bus, which then showed up in the list of offered connections. Aurelien took care of polishing the user interfaces of many of the dialogues the network management infrastructure uses, for example for editing connections. He also nailed a bug which would pop up two connection details dialogues when trying to connect to a wireless network.

We also did some design work, in order to determine which functionality we’ll offer, and how. I think the result of that is really nice, but not finished yet, so I won’t bother showing a screenshot. The design session we held showed one thing rather nicely, all the ideas we had fit very well into the current, two-paned UI concept without adding additional clutter, we’ll even be able to make the UI less complex and offering more functionality. I think that this is really the Plasma way, and in extension KDE 4 way of designing. Offer great functionality in a smart way, do not clutter the UI but create streamlined workflows.

So, what’s coming? Well, first off the networkmanagement plasmoid supports of course all different kinds of networks, wireless, VPN already. We haven’t yet tested mobile broadband, but are definitely planning to also make this a first-class citizen. You’ll also be able to see detailed information about your connections (no matter which way you choose to connect). You can choose to "just connect", but also to use a specific interface for a connection, so people with multiple network adaptors of the same type get full control.

I’m especially pleased that Martin, a.k.a. mofux jumped in to provide us with some kick-ass new artwork for the wireless icons. The artwork we had been using up until last week had pretty bad contrast issues with the Air theme, the new artwork is much better in that regard, and also a lot clearer and easier on the eye at small sizes. We’ve also added theming support here (through Plasma’s SVG theming mechanics), which is a nice bonus.

On particular pet peeve of mine is the connection status. I want to see how long I still have to wait until my network is up and I can do all those cool Internet things. Tooltips aren’t very well suited for this, and they have the tendency to go away just before I want them to. Also opening the connection dialogue is not good enough for me, since it involves manual interaction. I want to resume my notebook and see at once how far along my connection attempt is. What I have right now is I think already pretty close (though only 90% there from the beauty point of view). The idea is to show the progress as an overlay in the network management icon in the panel’s notification area. It’s now implemented as a pie chart, that starts at 12 o’clock and completes as the connection goes through its different stages, like connection at 802.11 level, authenticating (you’ll get a nice hint that a password is required in the panel as well) and configuring the IP address. For not so technical users, this is readable since it re-uses concepts well known from the real world, for the more technical folks (I tend to refer to them as propellerheads ;)), it provides more information than just a busy-spinner. As an example, if it "hangs" at 7 o’clock, you know that the DHCP config is taking its time. This is something that has been bugging me in other wifi configuration tools forever, so hurray, another step taken towards the best connection management tool in the world. :-)

So, is it finished yet? Well, no. It’s in a better shape than last week — which is not always a given, because sprints are often used for larger redesigns, and indeed we did improve some UI concepts that required parts of the code to be changed. Most importantly though, we’ve been making great progress at hard-to-fix bugs, and what’s left now is tying up a couple of loose ends. I’ve been hacking away on my list of changes to the plasmoid itself and I’m pleased with the progress so far. It’s not done yet though, but I expect that within a couple of days’ hacking, we’ll get there. I don’t see any particular blockers from my side right now, which is good. I’m confident that we can release a beta version shortly and give it some time to stabilise until it’s officially released as part of KDE SC 4.5.

This morning I’ve boarded the train of my second leg of the February round trip. I’ve spent a couple of days at the KDAB office, for a meeting of the team I’m part of. As usual, it was nice to meet with my colleagues. I was positively surprised by a great new feature in our Berlin office, a ping-pong table. I hadn’t played ping-pong in quite a while, so it took me some time getting used to lightweight and spinning balls, but I got up to speed quickly again and was even able to slash some of my colleagues a couple of times (you know who you are, no reason to embarrass you en plein public). Admittedly, I didn’t win every game, but let’s stick to the bright side of life.

Next stop on this trip is Nürnberg, in Southern Germany (it’s actually the city where the 3rd Reich’s race separation laws have been signed (the notorious "Nürnberger Gesetze"), but also the place where the Nazi trials after world war II were held as a display to the world that even those who do unimaginable harm to humanity were put to trial to have justice rule. Surely an interesting place from that point of view. After Tokamak, I’ll be meeting K in Düsseldorf next Friday, where we’re staying for the weekend, for a bit of sight-seeing and the Depeche Mode concert that will be held there on Saturday. From Jesper (KPhotoAlbum and KDAB training dude, and ), I’ve heard that Nitzer Ebb might be one of the support act. I didn’t know them yet (shame on me), so I’ll have to do some cultural catch-up before next week as well. (Fancy words for "listening to electronic music during hacking" ;)).

The reason why we’re in Nürnberg has nothing to do with history or music though. openSUSE has kindly offered us to host and sponsor (together with the KDE e.V.) three developer sprint that are closely related to each other: The 3rd Oxygen Meeting, a small KWin sprint (the first of its kind, to my knowledge) and the 4th installation of Tokamak, the half-yearly meeting of the Plasma team.

From a social point of view, I’m really looking forward to going to Nürnberg and meeting all those cool guys and gals that have become real friends over the years. Rather than going wild on how I love my fellow Plasma hackers, let me explain a bit what my personal plans for this sprint are. Those revolve around two topics, Network Management and Silk. In this blog entry, I’ll share some details about the network management infrastructure and UI we’ve been working on for almost two years now, and I’ll save Silk for another blog entry. You could also consider dropping by during the Open Day we’ll hold during the sprint, as I’ll be sharing some information about that in a presentation about Silk. Anyway …

Network Management

As you know, the network management tools in Plasma have been in development and "close to being ready" for quite a long time now. With 4.4, most distros ship the knetworkmanager tool, which is basically an icon in the Notification Area (system tray) offering a menu to choose your connection. Also in the works is a Plasma widget to do the same, but with a more attractive user interface. My work mostly concentrates on this applet.

Architecture

The overall architecture of the network management infrastructure in Plasma is a bit more complex than one might expect at first, but as you understand it, you’ll find out that It All Makes Sense. On the platform side of things of a typical Linux system, there’s the wifi driver stack, which is exposed to low-level tools such as WPA supplicant (and in extension to that networkmanager for example). Depending on the system, this could also be WICD, or Intel’s ConnMan (weird name, as Mike suggested yesterday during dinner). KDE’s network management tools sit on top of those lower-level infrastructure and put a unified user interface on top of that. The user doesn’t care which exact backend is in use, she just wants to get online, hassle-free and reliable. So KDE has a small network management client, which basically brokers information between the UI layer, and the middleware that takes care of the actual connection. This information can be "which wireless networks are available", "the user wants to connect to this network", "a password is needed to connect", and so on. So the information going through this broker is bi-directional. As communication channel, DBus is used. This broker is implemented as a kded module, a small plugin that is managed by a daemon in the KDE desktop (and which makes it possible to do "daemon-like" stuff by just writing a plugin, and reduced the number of processes that need running in the background). This daemon uses a backend for one of the lower-level connection tools, so that it abstracts away the differences between for example WICD and ConnMan. The Plasma Widget, when starting receives information from this DBus service and uses it to pass on user actions to the underlying infrastructure. So the layering is basically kernel – middleware – kded module – UI. Quite complex for something that’s presumably as simply as getting a network connection up, but it allows us to unify the UI for different systems, and hide system details from the user, while allowing her to choose the mechanism that works best, or is the preferred way of connecting for a given system. It allows you to use something else than NetworkManager if that doesn’t work for you for some reason, for example.

knetworkmanager vs. Network Management Plasma Widget

The tool that is currently the most reliable is knetworkmanager. A standalone application that embeds itself in the notification area. It uses the same set of libraries the network management kded module uses. This might at first be a bit confusing, because it sits one step lower in the stack than you’d expect. This is a shortcut actually, and more of an interim solution for us — it did allow us to test the abstraction and to get something working out to our users relatively quickly. Our goal is to get the Network Management Plasma Widget up to snuff. Some distros include the Plasma Widget already, but I’d only advise using it for the adventurous. If you just want something that works, use knetworkmanager for now. If you do want to try the Plasma Widget, there’s a catch though. In order to not get in the way of other clients (see below), we disabled auto-loading of the kded module for now, based on "we’d rather have something broken that isn’t supposed to be fully working anyway, than break the recommended tool". Sounds logical, right? :)

For NetworkManager, the situation is a bit special. There can only be one UI-client managing the NetworkManager daemon running in the background and taking care of the connection details. This means you can only use one out of knetworkmanager, GNOME’s nm-applet and the network management Plasma widget. Now let’s assume you’re adventurous, say a Lara Croft or an Indiana Jones of Free Software, and you want to check out the Network Management Plasmoid. First make sure it’s installed, this depends on your distro, so I won’t go into details here. Some will use KDE compiled from sources (you’ll currently find our stuff in kdereview), in that case you should be able to add the Network Management Widget to your Plasma Workspace using the normal "Add Widgets" mechanism. You’ll find yourself puzzled why it doesn’t work at first, but then you recall why that is, and of course you’re happy that you actually read this article. Then you stop the currently running network management thing (killall nm-applet, for those using the GNOME thing, kquitapp knetworkmanager for those relying on knetworkmanager at the moment). (kquitapp is the nice way of stopping a KDE application, it will make sure to cleanly quit and for example sync changes in the configuration to your disk, so it prevents possible data loss, compared to UNIX’ kill command. But I digress.) Of course it still doesn’t work (scroll up to re-read why!). Right, there’s something missing in between, the kded module, so there’s nothing to broker information between UI and lower-level infrastructure.

qdbus org.kde.kded /kded loadModule networkmanagement

will do that for you, and all of a sudden you’ll see available wireless networks showing up, and things looking less bare-bones and more promising. If you have your network already configured, you’ll see that you’re being connected automatically now (of course knetworkmanager and the Plasma widget share configuration, so they’re interchangeable), but you’ll also notice that some things aren’t working as expected yet, there are glitches in the UI, and some other bits that aren’t perfect yet. Those are the things we’ll be working on during Tokamak IV.

You might also find your setup not working at all. In this case, you’ll want to roll back, which means unloading the kded module the Plasmoid uses and starting your preferred client again. Unloading the DBus module is easy:

qdbus org.kde.kded /kded unloadModule networkmanagement

Then just run "knetworkmanager &" (for example), and you should be good to go again. (But you just lost some Lara/Indiana-karma of course, can’t have your cake and eat it, too.)

Finally, some personal words on Network Management in KDE SC. I feel kind of bad that we weren’t able to nail the whole network management thing in KDE SC yet. I think it’s one of those central components of system integration that should just work. Thanks to the work of Will Stephenson, we’re pretty close. As others have promised to jump in during the last days (Kevin, our Solid guru, Aurelien, Kubuntu-hacker extraordinaire, Shantanu of Plasmate fame and Sandro, who has been working on the cool KDE observatory in Plasma), Given this cool group, I’m pretty confident we’ll make good progress towards our goal. I hope that, by the end of next week, we have a working beta version of the Plasmoid in place, without known major bugs that we can hand out for testing by a wider base of potential users. From there on, it’s fixing bugs we haven’t seen yet, and ironing out smaller kinks. I’ll not be promising anything (I know better now ;)), but hard work is better than promises anyway, so let’s just see how far we get.

Special double-thanks go out to Will Stephenson, who has been awesome on both, the network management front and in hosting the Oxygen, KWin and Plasma bunch in Nürnberg.

Last night the launch of the new kde.org website, today the release of KDE SC 4.4.0, the past weeks have been rather busy in release-team and promo-team land. Let me just say that I’m glad that it’s finally out, that I want to say thanks to everybody involved for making this happen, and to all the users: Enjoy! :) KDE 4.4.0 is a very noticable upgrade to whatever you were running before, judging by the betas and release candidates.

Looking forward, this month has some travelling lined up for me as well. Next week, I’ll be going to Berlin to see my dear colleagues (and have them demo me Akonadi on my phone), then on to Tokamak4, the upcoming edition of the Plasma Hackfest in Nürnberg’s openSUSE offices, and after that a weekend in Düsseldorf with K for the Depeche Mode concert we had to miss last summer due to Dave Gahan’s bladder cancer.

I’ve written an article about KAuth, the new authentication framework in KDE SC 4.4. Earlier today, Linux-Comminity has published it. Go and read it (if you understand German) :)