There are three options:

1.) port the plugin over. nm-applet can only handle plugins that use the same libnm/libnm-glib.

2.) have every plugin we port build two versions. One with libnm, one libnm-glib.

3.) in nm-applet spawn another process that loads old plugins and can proxy the 
   functionality.


I vote for investigating 3rd option. If we can pull that off (with reasonable complexity) it would be best.

Doing 3.) is complicated and doesn't solve the problem for gnome-control-center.
So, 2.) it is (IMO).


But I think now is the time to significantly improve this. Namely, libnm should be able to load VPN plugins. But not the entire plugin including GTK dependencies.
This library provides meta information about the VPN. Such as import/export and more description about what the settings in NMSettingVpn mean.

so you do
  nm_vpn_plugin_get("vpnc")
or
  nm_vpn_plugin_get_for_connection(connection)

and possibly get a NMVpnPlugin instance (from the loaded shared library).


That NMVpnPlugin instance is also a way to access all the GTK related stuff that is currently in "/usr/lib64/NetworkManager/libnm-*-properties", but unless one of these functions is invoked, the GTK libraries should not be pulled in.

To be clear, we don't need to build 2 versions of *every* piece of the plugins.  There are 3 parts to each plugin:

1) auth dialog - standlone process talks over stdin/stdout, can simply be ported over to libnm

2) service daemon - standlone process that talks via D-Bus, can simply be ported over to libnm

3) GUI properties dialog - loaded via g_module() into nm-connection-editor and gnome control-center, *does* need two copies built, one for libnm-glib and one for libnm

So it's only the stuff in properties/ that needs porting in each plugin.

The only other thing I'd say is that we *can* improve it, but I wouldn't mind seeing a straight port over to libnm first, and *then* change/improve the libnm/gui-plugin API as a separate patch.  Just so that we are sure things work correctly in the libnm side, since there were a non-trivial number of bugs that we had to fix after we ported the applet over.

(In reply to Dan Williams from comment #3)
> To be clear, we don't need to build 2 versions of *every* piece of the
> plugins.  There are 3 parts to each plugin:

yes


> The only other thing I'd say is that we *can* improve it, but I wouldn't
> mind seeing a straight port over to libnm first, and *then* change/improve
> the libnm/gui-plugin API as a separate patch.  Just so that we are sure
> things work correctly in the libnm side, since there were a non-trivial
> number of bugs that we had to fix after we ported the applet over.

yes, *can*.

IMO having libnm load the VPN plugins has great potential:

  - currently loading plugins is duplicated:
       - panels/network/connection-editor/vpn-helpers.c
       - src/connection-editor/vpn-helpers.c
    instead, it could be done by libnm.
    I could imagine usecases where NM-core, nmcli, nmtui wants to load
    a (GTK-free) VPN plugin. If we do it now in libnm, it's already halfway 
    there.
   
  - Usecase of why "loading VPN plugins":
      - import/export in cli/tui.
      - NMSettingVpn:verify()?
      - meaningful connection editing in cli/tui
      - in general being able to know stuff about VPN connections. I see 
        potential there.

If we now just port to libnm without thinking about that usecase, in the future we must support 3 ways to load plugins, instead of 2. Which probably means, we will never do that, which means we miss out great possibilities.

In the complete version, this requires a split of the "properties" shared library into a non-GTK-part and a GTK-part.

But Ok, in step 1, we don't actually need that split. All I actually suggest is to have libnm load the plugins. In step 1 that is all that is needed, and later we can improve on that (like spliting out GTK-part, make actual use of any VPN functionality in libnm).

what I wanted to do is now in bug 749877.

seems that all VPN plugins are ported.

Closing.