One of the few utility programs that are used every day on mobile devices is a wireless networking tool, but somehow this is one of the last applications to appear for KDE 4. With the autumn 2009 crop of Linux distributions, a usable client for the widely used NetworkManager system finally makes its debut.

Why so long?



D-Bus connects the NetworkManager Server and Client D-Bus connects the NetworkManager Server and Client

So why did a native KDE 4 version of what is basically a system tray icon take three and a half KDE 4 releases to complete? There are several reasons. The original NetworkManager client was a GNOME applet and was developed in tandem with the server. Because of this, the NetworkManager interfaces for client developers were only partially documented. The NetworkManager system consists of a system daemon that receives network settings from a pair of settings services, one of which is run by the first local logged in user. This service supplies configuration information by placing Connection objects on the system bus. A client application sends commands to the service to activate these connections. One of the first tasks, therefore, was to take the D-Bus interface documentation system from Telepathy and apply it to the NetworkManager D-Bus interface. This was contributed to the upstream NetworkManager project, enabling up-to-date HTML documentation to be produced at build time so that other client authors can work without reading the NetworkManager C sources. Another reason was that the existing KDE 3 KNetworkManager needed many improvements to its user interface to fit in with other KDE 4 apps. It used the Qt3 D-Bus bindings, so this layer had to be completely rewritten as well. The current KDE 4 code shares only a few core algorithms with its predecessor. Finally, the KDE 3 KNetworkManager clients for NM 0.6 and 0.7 were developed entirely in-house at SUSE and never merged into KDE main modules, so few developers joined in and most of the work was done when necessary by SUSE engineers.

A new beginning, and a false dawn



The KNetworkManager menu The KNetworkManager menu

Will Stephenson of the openSUSE KDE Team took over responsibility for the KDE 4 NetworkManager client in 2007 from another team and began coding the base D-Bus layers using the new Qt4 D-Bus bindings. At the KDE 4 Launch Event in Mountain View in January 2008, he met with Celeste Paul, Christopher Blauvelt, Sebastian Kügler and others to develop a concept for a user-friendly yet powerful NM client. It was to be designed as a native Plasma Network Management applet for KDE 4.1, and shipped on several distributions. But this client had more than its share of flaws, mostly because the team spent much of its time dealing with layout problems in the very new QGraphicsView classes, instead of ensuring that NetworkManager features worked, and the design had grown naturally over time, resulting in an amorphous structure that was hard to work with. Then in May 2009, the KDE eV offered to sponsor a coding sprint in Oslo, where seven developers met and produced a workable design to go forward with. Throughout Summer 2009 this was refined, implemented and tested. The problems with the previous implementation led the team to produce a strongly layered design so that a simpler System Tray applet could be written first, running as an independent process so that any bugs could not crash Plasma, with most of the code in libraries that a subsequent Plasma applet can build on.

What KNetworkManager offers



Basic configuration Basic configuration

So what does the new KNetworkManager offer? At the least, a NetworkManager client provides user controllable networking. A system daemon receives configuration and commands from user programs. This is what the default nm-applet tool for GNOME offers. But since we were creating a new client from whole cloth, and with the experience of two KDE 3 clients and nm-applet to work from, we decided to improve on existing designs to make it as usable as possible. For example, where there are many wireless networks available, showing all the networks all the time in the applet's menu results in a screen-filling popup, making it hard to spot the network you wish to use. Instead, the applet only shows networks that you have used before out of those that are present. To connect to another network, or a previously used hidden network, a dialog provides a scrollable complete list, which can be easily filtered with a search line. Even though KNetworkManager is not built with the fashionable QGraphicsView used by Plasma for its UI, Qt allows a lightweight yet attractive interface, with menu items that display wireless strength and detailed security information, while other designs are still mockups. You can connect to networks with a single click in the popup menu, and its configuration dialog plugs into the standard KDE System Settings tool, making it easy to find there or in the popup menu.



The system tray applet with tooltip The system tray applet with tooltip

But that's not all we managed to fit in. Due to the modular structure of the code, we've already been able to attract new developers like Paul Marchouk to add polish and enhancements while the core was being completed. Features such as setting custom icons for a connection, configurable tooltips for both the hardcore networking specialist and the first time user, a choice between one icon for everything, or an icon per network interface (like in Windows), and a configuration UI for IP addresses that is 'better than OS X' have come from new KDE contributors. Other tweaks like storing passwords and other secrets securely or forcing them to be entered every time please administrators, and a Wireless Scan display lets you see what access points are in the neighbourhood.

But what about Plasma?

Some readers will be asking about the Plasma applet now. While this isn't being released yet, it hasn't stood still. The Oslo sprint design splits the user interface from the configuration UIs and the D-Bus services that do most of the work, so 90% of the KNetworkManager code will be used directly by the Network Management Plasma applet. Meanwhile, Sebastian Kügler is continuing to polish the code, and the layout issues have been fixed in Qt. We expect that the Plasma applet will be released as part of KDE 4.4.

Future directions



Detailed information on a network Detailed information on a network

While we hope that users of openSUSE 11.2, Kubuntu 9.10 and Fedora 12 will agree that KDE 4 KNetworkManager is useful for daily wired and wireless networking, and is mostly functional for 3G mobile broadband connections, there is still a lot to be done. The number of possible networking configurations mean there are still known and undiscovered bugs, which are being fixed now. A set of final icons are being prepared by the Oxygen team. Improvements for KDE 4.4 will include a minimal UI when creating new connections, showing only the password fields necessary, and better input verification to produce connections that work first time. Mobile Broadband will be improved by the inclusion of a database of ISPs, and support for the ModemManager interface will deliver cellular signal strength. IPv6 configuration should be available soon, and it will also be possible to create and edit system-wide connections so networking is up before users log in. And by passing information about connection usage to Nepomuk, queries such as 'Which files did I download at the office yesterday?' become possible. Finally, we hope that backends for other network management stacks such as wicd, ConnMan, and the in-house tools used by Mandriva and Pardus will be written, so that a KDE user will feel at home no matter which distro he/she picks up.

Distributions working for KDE, not the other way round



Extensive configuration settings Extensive configuration settings

Most of the the KDE 4 Network Management stack was developed by Will Stephenson as a Novell employee, but it is important to point out that this is an open and Free development, with and for every other distribution and end user to benefit from. Throughout the development we have liaised with Fedora and Kubuntu and exchanged bug reports, experiences, patches and even icons. The source code is in KDE SVN, and will shortly move to Extragear, and developer documentation will be available at TechBase. We hope that this serves as a model for other cross-distribution cooperation to benefit all of KDE.