The fact that NMRemoteConnection has to be an NMConnection and
therefore can't be an NMObject means that it needs to reimplement bits
of NMObject functionality (and likewise NMObject needs some special
magic to deal with it). Likewise, we will need a daemon-side
equivalent of NMObject as part of the gdbus port, and we would want
NMSettingsConnection to be able to inherit from this as well.
Solve this problem by making NMConnection into an interface, and
having NMRemoteConnection and NMSettingsConnection implement it. (We
use some hacks to keep the GHashTable of NMSettings objects inside
nm-connection.c rather than having to be implemented by the
implementations.)
Since NMConnection is no longer an instantiable type, this adds
NMSimpleConnection to replace the various non-D-Bus-based uses of
NMConnection throughout the code. nm_connection_new() becomes
nm_simple_connection_new(), nm_connection_new_from_hash() becomes
nm_simple_connection_new_from_hash(), and nm_connection_duplicate()
becomes nm_simple_connection_new_clone().
NMRemoteConnection had two DBusGConnection properties
(NMRemoteConnection:bus and NMRemoteConnection:dbus-connection) and
two D-Bus path properties (NMConnection:path and
NMRemoteConnection:dbus-path). The former of each pair were the
traditional names, and the latter were added for compatibility with
NMObject.
In libnm, we can just drop NMRemoteConnection:bus, and use the
NMObject-compatible :dbus-connection name instead.
For the path properties, we need to rename either NMConnection:path or
NMObject:dbus-path. Since NMObject already has "nm_object_get_path()"
rather than "nm_object_get_dbus_path()", and it already mistakenly
referred to the property as "NMObject:path" in the gtk-docs, it seemed
to make sense to rename that one rather than the NMConnection one.
(And then, for consistency, rename "nm_object_get_connection()" to
"nm_object_get_dbus_connection()" to also match its property.)
Remove NMRemoteConnection::updated, which since 0.9.10 has been
redundant with NMConnection::changed. (We still handle the incoming
D-Bus signal, we just don't re-emit it as "updated", since the call to
nm_connection_replace_settings() already results in it emitting
"changed".)
NMRemoteSettings duplicates a bunch of NMObject's functionality that
it doesn't need to. In libnm-glib, it wouldn't have been possible to
port NMRemoteSettings to NMObject without breaking ABI, but now in
libnm we can do that.
As a side effect of this, NMRemoteSettings gains a "connections"
property, and "connection-added" and "connection-removed" signals
(with the former replacing the old "new-connection" signal). This also
removes the "connections-loaded" signal, since the connections will
now always be loaded (via the initialization of the "connections"
property) during init()/init_async().
Also, this removes NMRemoteConnection's "removed" signal, since it's
redundant with the new NMRemoteSettings::connection-removed (and
having the signal on NMRemoteSettings instead is more consistent with
other objects).
"NetworkManager.h"'s name (and non-standard capitalization) suggest
that it's some sort of high-level super-important header, but it's
really just low-level D-Bus stuff. Rename it to "nm-dbus-interface.h"
and likewise "NetworkManagerVPN.h" to "nm-vpn-dbus-interface.h"
Remove _nm_object_ensure_inited(), etc; objects that implement
GInitable are now mandatory-to-init().
Remove constructor() implementations that sometimes return NULL; do
all the relevant checking in init() instead.
Make nm_client_new() and nm_remote_settings_new() take a GCancellable
and a GError**.
Most D-Bus interface name macros used "INTERFACE" in their name (eg,
NM_DBUS_INTERFACE), but a few used "IFACE" instead (eg,
NM_DBUS_IFACE_SETTINGS). Make them consistent.
This commit begins creating the new "libnm", which will replace
libnm-util and libnm-glib.
The main reason for the libnm-util/libnm-glib split is that the daemon
needs to link to libnm-util (to get NMSettings, NMConnection, etc),
but can't link to libnm-glib (because it uses many of the same type
names as the NetworkManager daemon. eg, NMDevice). So the daemon links
to only libnm-util, but basically all clients link to both.
With libnm, there will be only a single client-visible library, and
NetworkManager will internally link against a private "libnm-core"
containing the parts that used to be in libnm-util.
(The "libnm-core" parts still need to be in their own directory so
that the daemon can see those header files without also seeing the
ones in libnm/ that conflict with its own headers.)
[This commit just copies the source code from libnm-util/ to
libnm-core/, and libnm-glib/ to libnm/:
mkdir -p libnm-core/tests/
mkdir -p libnm/tests/
cp libnm-util/*.[ch] libnm-util/nm-version.h.in libnm-core/
rm -f libnm-core/nm-version.h libnm-core/nm-setting-template.[ch] libnm-core/nm-utils-enum-types.[ch]
cp libnm-util/tests/*.[ch] libnm-core/tests/
cp libnm-glib/*.[ch] libnm/
rm -f libnm/libnm_glib.[ch] libnm/libnm-glib-test.c libnm/nm-glib-enum-types.[ch]
cp libnm-glib/tests/*.[ch] libnm/tests/
]
