KDE needs as an entire project to support a Web browser that everyone can use in 2009. That's the simple message behind this blog entry and my talk at LinuxTag on Saturday.

If you need any more motivation to go out there and make that happen, read on.

On Sunday the work continued at a furious pace. Dario carried on moving the connection list generating code out of the applet and into the KDED module. This makes the applet much simpler and easier for Plasma specialists to improve. We considered using a Plasma DataEngine or Service, but decided not to for now because it adds another layer of indirection. For NetworkManager at least, if the settings service process leaves the system bus (due to a deliberate or accidental exit) you fall offline. The settings service and Plasma are both complex programs, so combining them increases the chances that a bug in one can crash the other. So we put it in a different process, forcing one layer of indirection already.

Meanwhile Frederik Gladhorn and I were refactoring the storage layer for Connection settings so that it is independent of NetworkManager. One of the good things about NetworkManager's settings is that they are so comprehensive the classes I developed to configure them cover all of wicd's settings too. Frederik namespaced the general classes while I moved the DBUS code that is specific to NetworkManager 0.7 out of the libs/ directory. Since it is generated automatically from some .kcfg files by a modified kconfig_compiler and then extra stuff is patched into those files, this was quite a lot of work.

Our students from the University of Bergen, Anders, Peder and Sveinung, were busy working on the mobile broadband improvements for their degree group project. This includes a set of DBUS bindings for the ModemManager auxiliary interface of NetworkManager, which were used to successfully send an SMS and will support useful functions like retrieving cellular signal strength, a set of Qt widgets around libmbca, taking the pain out of configuring cellular data connections, and a test harness. We hope they will continue with KDE development after they graduate.

The status of Network Management as of Sunday 7 June then is that it doesn't even compile. I'm working on remedying that as soon as possible. If you do want to use Network Management from SVN, take a safe revision like r978079 until you hear otherwise.

We'd like to thank the Trolls for being great hosts and the KDE eV for sponsoring this sprint.

I felt like the grumpy grandpa of the NM sprint when the others hammered on my door at 9.30am after I'd rolled over for just another 10 minutes two hours earlier. The grey cells do still work once you hit your thirties but they need more care and feeding if I want to be able to speak intelligibly the next morning - not going to rock bars until 3am!

We've continued planning this morning. The big goals for this meeting was to 'get Network Management finished' and 'make it usable on non-NetworkManager systems' but our discussions last night showed us that the current complexity of the applet prevents both goals - it takes me several days of getting up to speed with the code before I dare to try to code it and it's deterring Frederik from making significant changes. So we identified all the pieces and started juggling them last night over pizza until they landed in a way that makes sense.

The big picture is that most of the complexity will move from the Plasma applet into the KDED module. This module will abstract different network management systems by being replaceable. The module provides a simple list of the things to show in the applet's popup. Configuration UI and stored settings are to be shared - we think that the current (NM-derived) settings schema is comprehensive enough.

There's a temptation to write an über-system that models everything and allows any number of applet implementations but we're resisting that as it would never be finished. I'm a little bit disappointed that we won't be adding a lot of polish and nice to have features but a sprint is the ideal time to swing a large hammer at hard architectural issues that otherwise would stunt Network Management's growth.

I pried my eyes open at 0430 and stumbled to the airport. This all started about a month ago when we had the idea of having a developer sprint to get Network Management into shape in time for KDE 4.3's release. Now I'm sitting in a meeting room in Oslo listening to the progress report of 3 Norwegian students Peder, Sveinung and Anders who are investigating ways to make setting up mobile broadband connections easier. Thanks to the KDE eV's sponsorship, six of us are meeting this weekend. TODOs include cleaning up UI glitches, fixing some exotic VPN types and auth types and deciding how to abstract different backends like wicd and ConnMan.

If you want to help out or just rubberneck, we're in #solid.

Martin Schlander already said the most important things but repetition never hurt a good message:

• KDE 4.3 is coming to KDE:KDE4:Factory:Desktop<. If you do nothing and use this repo you will get KDE 4.3beta1 installed soon!
• The stable KDE 4.2 packages will continue to be available in the new KDE:42 repo.
• The Extra-Apps repo is gone, its packages merged into Desktop, Community or Playground according to their level of support and release readiness.
• App packages which have both KDE 3 and KDE 4 versions are being renamed to show that KDE 4 is the default. Eg for digikam, we have kde3-digikam and digikam-kde4. This will cause a package upgrade to the new stable version. If you want to keep the KDE 3 version, install the kde3- package instead of the new KDE 4 based package.
• The Geeko is a quiet and stealthy animal. It doesn't make a lot of noise. But it produces solid, well engineered Linux distros year after year. Stephan 'Unstoppable Force Beineri' Binner has produced a respin installation CD of openSUSE 11.1 containing the latest and greatest KDE 4.2.2, and all the online updates since 11.1 came out in December. Is the longer openSUSE release cycle making you twitchy for a hit of something new? Do you want a rock solid openSUSE with the best KDE has to offer and none of this repo-fiddling nonsense? Get the respin from: http://download.opensuse.org/repositories/KDE:/Medias/images/iso/.

A promising student was talking with me about working on Network Management in GSoC 2009, but decided to concentrate on his studies this summer. Out of the discussion I've created this idea proposal. In case anyone is interested in making mobile broadband connections really easy to do in Network Management, see the KDE Google Summer of Code 2009 ideas page.

A helpful chap just popped into #opensuse-kde and asked about our c# bindings. It turns out that our packages exclude them in the most violent way possible. This made me curious as to why, as AFAIK they are a high quality binding that exposes the Joy Of KDE to an untapped pool of developer talent. The reason is lack of obvious demand and anyone to test them. So I'd like to know, if we enable building the (stable) Qyoto bindings for C#, would you use them?

I'm drinking my Saturday morning tea and looking back on a pretty crappy week. I was burning the candle at both ends to get various enterprise stuff finished in time, and didn't have enough energy to really enjoy FOSDEM. Here are the openSUSE devroom slides from FOSDEM 2009.

Looking forward, I've been tidying up my computers, installing openSUSE Factory (the alpha0 edition before anyone knows when 11.2 will really be done, and before everyone starts breaking things in earnest), deleting dozens of Build Service checkouts that were finished or forgotten about, and purging my unorganised piles into nice clean GTD lists. That's giving me some peace of mind to think about what to do for KDE on openSUSE 11.2. We'll be having an IRC meeting next Wednesday (1700UTC) to coordinate the team's efforts, but I'm starting to think about things I could do myself. Things like a return for KPersonalizer, a KControl-like treeview for System Settings, or helping tame the Plasma Activities/Zooming UI system into something usable. That and of course completing Network Management (oh, did I let slip the name we chose?). If anyone is already working in those areas, please let me know.

EDIT: Oh and I should point out that openFATE is of course open for business and waiting to receive your ideas. Find out how to use openFATE here.

I took a few pictures of KDE people and the area around the hotel most were staying in. Click for the rest:

I'm nearly ready to move NetworkManager-kde4 to kdereview now, after a crazy week of rehashing the connection layer (the bit that writes your configured connections to KConfig (and optionally KWallet) into something that I actually want to support for a few years.

Before I move it and start telling people about it, I want to decide on a final name. This is important as it's not just what appears in the UI, but also determines the names of files like config files for connections, KNotify settings, translation catalogs, none of which you want to mess about with after a release. So I'm looking for suggestions for and opinions about a good name.