Search This Blog


Saturday, October 22, 2011

Plasma NM: what is going on (libnm-qt and libmm-qt)

As I wrote during the last Solid Sprint we are working to bring libnm-qt and libmm-qt to Plasma NM. Libnm-qt is a Qt-only  wrapper around NetworkManager's API and DBus interface. Libmm-qt is the same for ModemManager's DBus interface. Both libraries were created by Will Stephenson for NetworkManager 0.8 and ModemManager 0.4. Ilia Kats ported libnm-qt to NetworkManager 0.9 API during the Sprint. Thanks to both for working on that.

This week I have started to port Plasma NM to libnm-qt, I had to do some changes in libnm-qt and libmm-qt to allow Plasma NM to compile against it, nothing that special. There is still a long road to go, according to cmake I can compile about 31% of Plasma NM's +57K lines source code, not counting the auto-generated .cpp and .h, nor the .xml files used to generate them. Some parts of Plasma NM are going to be refactored since libnm-qt implements them itself. Fortunately, that also means Plasma NM's source code is going to shrink a bit.

libnm-qt is basically the Solid's NM backend (networkmanagement/solidcontrolfuture/solid/networkmanager-0.9) refactored to work as a public library instead of a private backend of networkmanagement/solidcontrolfuture/libs/solid/control/network*. The same is true for libmm-qt, kde-workspace/solid/modemmanager-0.4 and kde-workspace/libs/solid/control/modem*. All this means we are finally getting rid of Solid::Control classes (a goal from last year's Solid Sprint). KDE SC 4.8.0 is not going to use Solid::Control anymore, but libnm-qt and libmm-qt are going to be dependencies for any KDE program that needs to list network interfaces (kinfocenter for example). Update 23/10: removing Solid::Control::Network* now would also remove part of Wicd's support, so for now I will not remove Solid::Control until we figure out a way to support NetworkManager, Wicd and possibly Connman.

The final goal with libnm-qt and libmm-qt is to move than to NetworkManager's repository so that NM guys can help to maintain them. That is for next year, probably. We still need to get the libraries ready before that happens.

Now applications can retrieve network status (online, offline) using either kded's networkstatus module, which does not depend on libnm-qt and works for NetworkManager and Wicd, or libnm-qt.

You can find both libnm-qt and libmm-qt in git:// Be warned that sometimes I do break their ABI.

I am also going to release Plasma NM 0.8.90 (0.9.0_rc1) today. I am just waiting for the tar bal to reach Stay tuned for the announcement.

So that is what is happening in KDE's Network Management front :-)


emilsedgh said...

Hi Lamarque.

I just switched to plasma-nm's nm09 branch. It worked flawless for my simple usecase (connecting to wlan). I thought I should say thanks.


pprkut said...

"KDE SC 4.8.0 is not going to use Solid::Control anymore, but libnm-qt and libmm-qt are going to be dependencies for any KDE program that needs to list network interfaces (kinfocenter for example)."

How does that affect the network backend transparency of solid? Ie, what happens if one wants to replace NM with eg wicd or connman?

Kevin Krammer said...

Of course, kded's networkstatus works only inside a opened KDE session though.

I think kded is always available when a KDE program runs, independent of whether the workspace session is managed by KDE's session manager

Lamarque said...

@emilsedgh, thanks.

@pprkut, hmmm you got a point. We can still use Solid::Control::Network* until we figure how to deal with this problem. Anyway, since I am very busy I can postpone the Solid::Control removing to 4.9 or whatever version there will be in year or so.

@Kevin Krammer, I think you are right. I only use Plasma Desktop, so I do not know how exactly KDE programs work in other environments.

dfaure said...

In case anyone else ends up at this blog when googling for "where do I get libmm-qt for", the answer is nowadays: git://

KenP said...

I use VPN to my office network regularly as KDE runs on my work laptop. However, networkmanager (kde) fails to connect to the VPN.

My corporate VPN is pptp and requires a one-time passcode, which means I cannot save the password -- which nm forces me to. If I choose "Always Ask", it does not work and does not prompt me for the password. This has been tested in 4.7.80 (beta1) release as well.

I am forced to fallback to nm-applet from networkmanager (gnome).

Is there a roadmap to fix VPN issues once and for all?

nm-applet from gnome version has been doing stable VPN (all kinds) for at least over a year now.


Lamarque said...

@KenP, this is not the correct place to report bugs. Please fill a bug in about this problem.

4.7.80 is KDE SC version, not Plasma NM's. Current Plasma NM version is 0.8.98.

There is no official roadmap. I am basically working alone most of the time to fix bugs in my spare time. I also do not have access to a pptp server. I do have access to a VPS where I can install pptp, I have never done that :) I already installed an OpenVPN server there for tests. I will try to install pptp there and try to reproduce the problem.

Can you send me all the configuration you use? pptp server version, a mini-howto on how to set it up for passwordless login and the configuration you entered in Plasma NM would be appreciated too.