Because object-valued properties (like ip4-config) get reloaded
asynchronously when they change, we will still have out-of-date values
for them cached at the point when we get the StateChanged signal from
the daemon. Work around this by manually reloading all properties
before emitting the client-side signal.
Also, fix a dumb bug in NMObject...
In some situations, objects might get used after being disposed, so
clear out their various priv fields so we don't try to access unreffed
objects, freed strings, etc.
https://bugzilla.gnome.org/show_bug.cgi?id=674473
We need to do _nm_object_ensure_inited() /
_nm_remote_settings_ensure_inited() from the get_property()
implementations; in most cases, get_property() just calls another
accessor method (which will call _nm_object_ensure_inited()), but in a
few places, it reads priv->whatever directly, so we need to make sure
that it's valid.
Add nm_device_connection_compatible() that returns an error when it fails.
nm_device_connection_valid() does the same work except it doesn't set GError.
NM emits coalesced PropertiesChanged signals, which might be
delayed slightly and thus sent after the StateChanged signal
for devices. Clients of libnm-glib listening for the
'state-changed' signal and then querying the state manually
using nm_device_get_state() would still see the old state until
it was updated via the delayed PropertiesChanged signal
processing. Since when the StateChanged signal comes in the
device is already in the new state, just update the state and
leave the GObject property notify signal to the
PropertiesChanged signal handling code so that clients have
an accurate device state.
Fix handle_object_array_property() to deal with receiving an empty
list correctly (rather than warning and leaving the property with its
previous value still set).
Also, add two more untracked properties that shouldn't be warned about
(NMDevice:device-type and NMActiveConnection:vpn, both of which are
only used at construct time).
Rather than generating enum classes by hand (and complaining in each
file that "this should really be standard"), use glib-mkenums.
Unfortunately, we need a very new version of glib-mkenums in order to
deal with NM's naming conventions and to fix a few other bugs, so just
import that into the source tree temporarily.
Also, to simplify the use of glib-mkenums, import Makefile.glib from
https://bugzilla.gnome.org/654395.
To avoid having to run glib-mkenums for every subdirectory of src/,
add a new "generated" directory, and put the generated enums files
there.
Finally, use Makefile.glib for marshallers too, and generate separate
ones for libnm-glib and NetworkManager.
Implement GInitable and GAsyncInitable in NMObject, with
implementations that synchronously or asynchonously load all
properties, and change _nm_object_ensure_inited() to run
g_initable_init().
Update the object/object-array property handling to initialize the
objects after creating them (synchronously or asynchronously,
according to the situation), so that they will have all of their
properties preloaded before they are ever visible to the caller.
Move the non-blocking/non-failable parts of various objects'
constructor() methods to constructed(), and move the blocking/failable
parts to init(), and implement init_async() methods with non-blocking
versions of the blocking methods.
Make nm_device_new() and nm_client_new() call
_nm_object_ensure_inited(), to preserve the behaviour formerly
enforced by their construct() methods, that properties are guaranteed
to be initialized before any signals involving them are emitted.
Add an "object_type" field to NMPropertiesInfo, and use that with
DBUS_TYPE_G_OBJECT_PATH and DBUS_TYPE_G_ARRAY_OF_OBJECT_PATH
properties so that we don't need custom marshallers for each one.
When creating an NMDevice or NMActiveConnection, we need to fetch an
extra property first to figure out the exact subclass to use, so add a
bit of infrastructure for that as well. Also, do that preprocessing
asynchronously when processing a property change notification, so that
it doesn't block the main loop.
Rather than having every property getter method have code to fetch
that specific property's value, just call the new
_nm_object_ensure_inited() (which makes sure that we've read all the
property values on the object at least once), and then return the
cached value. (After we've read the initial property values, the
PropertiesChanged signal handler will ensure that the values are kept
up to date, so we can always just return cached property values after
that point.)
This then lets us get rid of _nm_object_get_property() and its
wrappers.
Rename _nm_object_handle_properties_changed(), etc, to be about
properties in general, rather than just property changes.
Interpret func==NULL in NMPropertiesInfo as meaning "use
_nm_object_demarshal_generic", and then reorder the fields so that you
can just leave that field out in the declarations when it's NULL.
Add a way to register properties that exist in D-Bus but aren't
tracked by the NMObjects, and use that for NMDevice's D-Bus Ip4Address
property, replacing the existing hack.
Also add a few other missing properties noticed along the way.
Most of the code was using dbus_g_proxy_call() directly, but there
were some leftover uses of the generated bindings. Make things more
consistent by using dbus_g_proxy_call() everywhere, and stop building
the -bindings.h files.
NMClient and NMDevice used a 'lazy' approach for getting stuff from D-Bus, i.e.
requesting data from NM when they are asked for. However, for some cases, like
removing devices it is not optimal. libnm-glib will never see a device that was
removed, but not added during NMClient's lifetime.
So let's get devices list in NMClient's constructor and device properties
in NMDevice constructor to have the data from the beginning.
G_VALUE_HOLDS will fail if the value variable is NULL, so we only
want to check that the GValue holds the right type if the value
is valid. NULL means "no object path" in demarshallers.
Since D-Bus doesn't allow NULL or zero-length object paths, NM
uses "/" as a placeholder here. Make sure the generic marshalling
code handles that so we don't have to do it in multiple places and
simplify handling of NULL objects somewhat.
Like the *_filter_connections() functions, but for just one connection,
and now the *_filter_connections() functions call these new ones so
it's really just moving code around and not anything new.
These new functions more closely match the usage I've seen from
gnome-shell's network.js and elsewhere.
These days more and more devices are showing up that support a
number of different access technology families in the same hardware,
like Qualcomm Gobi (CDMA and GSM), Pantech UM190 (CDMA and GSM),
Pantech UML290 (CDMA and LTE), LG VL600 (CDMA and LTE), Sierra
320U (GSM and LTE), etc. The previous scheme of having device
classes based on access technology family simply cannot handle
this hardware and attempting to add LTE to both the CDMA and GSM
device classes would result in a bunch of code duplication that
we don't want. There's a better way...
Instead, combine both CDMA and GSM device classes into a generic
"Modem" device class that provides capabilities indicating what
access technology families a modem supports, and what families
it supports immediately without a firmware reload. (Gobi devices
for example require a firmware reload before they can switch
between GSM and CDMA). This provides the necessary flexibility
to the client and allows us to keep the API stable when the
same consolidation change is made in ModemManager.
The current code doesn't yet allow multi-mode operation internally,
but the API is now what we want it to be and won't need to be
changed.
Add the necessary annotations (the mininum required, that is those
on return values. NULL parameters or container types may require
more), and the Autotools stuff to get a NetworkManager GIR for
libnm-util and a NMClient for libnm-glib.
Heavily modify Inaky's Intel WiMAX SDK glue (originally from connman)
to be more generic and more thread-safe, and suitable for use with
NetworkManager instead of rolling our own client code. Rewrite the
NMDeviceWimax code to mostly work.
Still to be done: actual connection logic, DHCP handling, spawning
wimaxd if it's not started yet
