Category: KDE

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) :)

So tonight, release-team-hero Dirk has branched off KDE SC 4.4 from trunk. Let quickly explain what this means. Trunk/ is a directory in KDE’s SVN repository, the central place holding where all the code from different contributors spread across our planet comes together. In a big team like KDE, we need some coordination to be actually able to release our software packages once in a while. Since the release of KDE 4.0.0, a typical KDE release cycle takes 6 months. Roughly 4 months of development, followed by about 2 months of stabilization and testing towards a release. In the stabilization period, which starts with the feature and string freeze, only bugfixes and code improvements are allowed. This is also the period where we release regular test releases, in our case a beta1, right after the feature freeze, and a second beta (happened shortly before christmas). The next test release is coming soon, which is -rc1.

This time around, we have slightly changed the original schedule. This made it possible to depend on Qt 4.6 with KDE 4.4. Between the release of Qt 4.6.0 and KDE 4.4.0 needs to be a bit of time. The release brought a lot of changes and new features, so a bit more testing is in place. In a complex software stack like the KDE one, there’s many cases you can only find and fix with enough people running it. So we inserted an additional two weeks, which makes us align nicely with the new Qt, in fact there will be a Qt 4.6.1 available with a number of fixes that are pretty much essential for running Plasma and many KDE applications, like global shortcuts which has been a problem recently (a fix for that will be in 4.6.1, Thiago told me). We’ve inserted another release candidate, so there will be an -rc2 before KDE SC 4.4.0 is out, as you can see in the release schedule. KDE SC 4.4.0 will be released on 9th February. The x.y.0 releases are followed by monthly updates, which bring bugfixes and new translations.

I’ve done a clean build of KDE 4.4 trunk last night, and I must say I’m quite impressed. There’s a good amount of polish added, everything feels smoother, faster and a couple of really nice features have been added (Blogilo, the program I’m using to write this article, for one). I’ve also test-driven the new netbook-shell in KDE 4.4, and am really happy with it so far. I think, even with the huge amount of changes that went in, KDE 4.4.0 will be a very nice release already, followed up by the monthly bugfix and translation updates of course to provide fixes that arise post 4.4.0. The translation cycle of KDE (there are more than 50 languages available for KDE 4.4), differs a bit from the release cycle. Translators cannot sensibly work off of a constantly changing base. That’s why the feature freeze goes along with a string freeze. This way our localisation teams get the chance to produce a well translated release — something that might not matter a lot to many developers who run bleeding edge english UIs that haven’t even had a chance to get translated. The string freeze makes sure that no new translations are added. Starting with the string freeze, translators are constantly updating the translations for the test releases and then from the 4.4 branch, this way, our x.y.1+ releases are also ever more complete in other languages. In the end, he 4.4.2+ releases is what many people will actually be running for a while, so it’s important we provide a series of updates for them.

So much for a "quick "explanation of how the release process works. In the first paragraph, I told that KDE SC 4.4 is now branched off from trunk. This means that we now start to maintain the KDE SC 4.4 series in a separate directory in KDE’s SVN repository. It also means that if you have an SVN checkout pointing to trunk, you will now get what is to become KDE 4.5 this summer. Anything you commit to trunk from now on will not automatically appear in KDE 4.4.0 and its subsequent releases. That in turn means that through the normal distribution route, your particular patch will not end up on an end-user’s machine before somewhen in fall 2010.

There’s two ways to get those fixes that you’re making faster to the user:

• svn switch to the 4.4 branch. This is actually what you should do (in the ideal world of the release team’s people, anyway). It would be good to have as many people as possible working with the 4.4 branch, at least until we tag 4.4.1. This makes it easy to fix the first wave of bugs we’re getting in after the release of 4.4.0. It’s basically the issues people find who don’t run betas (but are willing to install additional packages by hand to get a newer KDE)
• svnbackport fixes you make. If you are working on some code and are fixing something, consider backporting this to the 4.4 branch (in case you’re using trunk, or another work branch). In kdesdk/scripts, you can find the excellent svnbackport script, which makes it really easy to commit a certain patch also to a branch. It can be as easy as one command, and your users might get a fix 6 months earlier.

While trunk is unfrozen (thawed?), the 4.4 branch of course stays frozen. In there, you shouldn’t commit new strings that would need translation, also new features should only be added to trunk.

As Aaron mentions in his retrospective article, the release team is well in place. I have to agree there. My experience as the "dude who does the announcements" is that the collaboration is really good and natural. We manage to keep the amount of policy sane (believe me, we do!), and we do actually succeed in getting good and stable releases out the door. We’ve hardly slipped our 6 months cycle since the release of KDE 4.0, 2 years ago. And we make our users (new and potential) happy with regular releases, and then actually care about them and supplying monthly updates. The work within the team is also pretty relaxed. For all the work that needs to be done, we have responsible and reliable people that "do the actual thing", we keep short communication lines. At the same time, the decision-making processes feel very natural. KDE does not have a benevolent dictator other big projects (the Linux kernel as a popular one), instead decision-making is done by "those who do the work", taking input from others. Decisions are taken by consensus. This might lead to deadlocks in some cases (strong opinions on either side), but it appears to work really well for KDE development. This takes a bit of discipline from everybody, but I think it yields great results.

Lastly, Dirk (one of "those who do the work") tagged KDE SC RC1 tonight. Tagging means creating a copy of the KDE SC in KDE’s SVN repository, which is then smoke-tested and tarred up as release (and sometimes amended with a last minute critical fix). The tarballs are then uploaded to the FTP master, which distributes the source code packages to the local mirrors, we usually give the syncing 4 – 6 hours, and then announce the release on kde.org, the Dot and to the announcement mailing list. Normally, we’ve put about one week between tagging and actual release. This gives us some time to test the packages (does everything work? does it compile with all likely combinations of dependencies and platforms? and so on). Within this week, the packages from various distros get the packages already, so that they can provide zero-hour packages to their users. (Ever read a release announcement, drooled, and immediately wanted to install it? — This is why zero-day packages are important!) For the test releases, we felt that it’s more important to get the test sources out to the users as quickly as possible, since the version people test with should be as close to what developers are working on (trunk) to make fixing bugs and confirming something’s fixed easier. So RC1 might be out as soon as tomorrow, as it looks quite solid up until now. It means that there might not be zero day packages for those test releases, but it also means that nobody needs to hold back fine RC1 packages until the release team peeps give their blessing.

Thanks for reading all of it, I hope it was entertaining, interesting or enlightening, and that it gives a better idea about some of the inner workings of KDE. My next blog entry will contain a screenshot. I promise. :-)

I went to Berlin last week to spend a couple of days with my colleagues at the new KDAB office. The new location is in Kreuzberg, just like the old one, but a bit closer to the city centre. It’s very spacy (about 3 times the size of our previous office near Oranienstrasse), so of course there’s plenty of space to host the foosball table. There are also new training rooms, including a meeting room. While not everything is fully equipped yet, it looks very neat and shiny. The perfect environment for a few days of intensive training courses (with good food and other distractions nearby). It’s also quite cool to have the training facilities right next to our office, so we can always call in a specialist for very detailed questions. The Qt Experts at your fingertips, so to say :)
If you’re interested in those trainings as well, some of my colleagues will be present at Camp KDE, to be held next month in San Diego, California. There will be more general Qt trainings (I followed on given by Till last year, and it’s a really excellent opportunity to get some hands-on experience with topics that would take you weeks to cover on your own because of their complexity. I read that we’ll also do a more specialized training course for Qt in embedded scenarios, surely interesting if you’re into “beyond the desktop” kind of topics. KDAB has been working with this kind of stuff for years, and the training courses are fun and interesting to attend, make sure you don’t miss out! I myself won’t be present, since I’m trying to make my desk-time/travel-time ratio a bit more favourable lately (with mixed success, but I’m trying!).
One interesting details was that after arriving in Berlin, when I was trying to find the right door to our (KDAB’s) new office, I noted a sign for Apliki sign close to the KDAB office. Apliki is the company who is working on icon testing, with their most recent icon test the kmail and kontact icons. So I sent Björn an email, and he came over after work for a bit of chat, a beer and a foosball match. He also showed us the backend for the icon testing web application Apliki has developed, which was really interesting since it provides a way to “measure” usability aspects. Unfortunately, usability is often mistaken as an argument to push your own opinion on a UI, why you like it or why you don’t. These tests provide a good way to quantify the recognizability of icons, and thus allow for a less biased view on how well an icon represents a certain action (or status, object, whatever). The backend looked very slick, and allows for more complex correlation of data. Meeting Björn was of course pure coincidence, but just shows how nice and Free software friendly a city Berlin is.

Working with colleagues was one part of the purpose of my trip. As some of you might know, I’ve been serving in the last years on the Board of Directors of the KDE e.V., the foundation to support KDE. We have recently moved our office from Frankfurt, where we started out a couple of years ago to Berlin, which was more practical with Claudia, our business manager living there, and of course with Berlin being the Free software capital in Germany. We’re sharing the Berlin office with our friends from the Free Software Foundation Europe, which is also very nice since there’s a lot of experience, resources and contacts to share, and our goals largely align — while their implementation doesn’t. In short, nice neighbours of which I got to meet some more last Saturday. The party was really nice, about half of the people had FSFE background, the other half KDE backgrounds with a lot of overlap. I’m happy that we found such a nice place with nice people in Berlin’s city centre (the office is in Linienstrasse, about 150m from U-Bahn Oranienstrasse, which is pretty much spot-on city-centre.

On Friday night, Sebastian Sauer (or dipesh, the guy responsible for Kross and its extensive scripting capabilities in KDE) went to Maelcum’s (that’s the guy who implemented proper SSL support in KDE 4) house warming party. After that, we went back to Kreuzberg to hang out a bit at Breipott (note the creative use ot the TLD :)), a bar with live DJ’ing and lots of Free music. You can just bring your USB stick there and copy music you’ve found — completely legal and encouraged. A really nice Free culture showcase.

Logistically, it all worked out pretty well. I had some productive days at the KDAB office (with also some less productive parts after work — true to our mantra of “work hard, play hard”), and could combine it with some KDE business. On the way back from Berlin on Sunday, I visited my mother and met with other family members I don’t see that often before collapsing at home early that night. Those days rocked, but were exhausting nevertheless.