KDE NetworkManagement Sprint Day Three and Wrapup

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.


Hello to KDE network management developers!

If I understand correctly, It won't be possible for the computer to log / connect onto the network before logging in into KDE ?

There are some cases where it's nice to have this possibility :
* You get network in console mode. Highly useful when your X server is broken for whatever reason. It happens to me regularly because of nvidia drivers (yes, I know, proprietary, but still) : I need to download the nvidia drivers again, or google some help (links is useful :))
* When using a wifi connection that takes time to establish, it's better to start connecting long before logging in to KDE. That way one is already connected when logged in (and it avaoid gazillion error message because there is no network).

What do you think ?

And thank you for all your hard work !

By gaboo at Mon, 06/08/2009 - 14:45

NetworkManager 0.7 gets its connections from two DBUS services:
* NetworkManagerUserSettings
* NetworkManagerSystemSettings

The latter exposes any system-wide configured connections, and does so when NM itself starts. So you should have network on boot.

If you need to mess with network settings without X check out my colleague Martin Vidner's cnetworkmanager tool. It's a Python console utility for basic connection types.

By Will Stephenson at Mon, 06/08/2009 - 15:23

Well, cool, thanks :)

By gaboo at Thu, 06/11/2009 - 07:58