GObject _new constructors should always return a new pointer and not do
anything else than g_{object,initable}_new(). Drop the internal
up_client_object singleton instance.
This simplifies the code and makes the code robust with multiple threads.
Side issue in https://bugs.freedesktop.org/show_bug.cgi?id=95350
A GObject's _init() should never fail or block, but this is currently the case
as up_client_init() connects to upowerd on D-Bus. Convert this to the GInitable
interface and provide a new constructor up_client_new_full() which accepts a
GCancellable and GError, so that clients can do proper error handling
and reporting.
This changes up_client_new() to return NULL when connecting to upowerd fails.
This provides a more well-defined behaviour in this case as clients can check
for this and our methods stop segfaulting as they have checks like
g_return_val_if_fail (UP_IS_CLIENT (client), ...)
Previously we returned a valid object, but trying to call any method on it
segfaulted due to the NULL D-Bus proxy, so client code had no chance to check
whether the UpClient object was really valid.
https://bugs.freedesktop.org/show_bug.cgi?id=95350
This allows using e.g. g_autoptr(UpDevice) in other programs, but does
not make upower itself use g_autoptr, or require a new enough glib to
support it.
Signed-off-by: Richard Hughes <richard@hughsie.com>
And make device-removed send an object path, not a UpDevice.
This means that we don't keep all the remote devices as local
UpDevices object, getting woken up any time any of them have a
property changed, without anybody listening.
This should greatly cut down on the wakeups on the client side,
especially for applications that only use a small portion of the API
like the "on-battery" or "warning-level" properties.
Now that we send out PropertiesChanged signals (on the daemon side)
and "notify" signals (on the client side), there's no need for the
all encompassing DeviceChanged and Changed signals.
They would have woken up any client, even if they were not interested
in receiving the signals.
This allows desktop front-ends to get which action will
actually be taken when we hit critical battery.
This is not a property as availability of actions might
change over the course of the run of the system, and
we didn't want to make unnecessary D-Bus calls on startup.
gnome-settings-daemon creates a composite UpDevice that's not
backed by any real D-Bus object in UPower, so we shouldn't
try and poke the inexistant proxy in this case.
We'll cache the properties that the caller sets in this case,
but will not support sending back default/unset values.
It was added for some workloads, but ill-suited and never really
got traction. Using cgroups to manage the resources of particular
services (using systemd), or something separate like rtkit is
a better bet.
The recalls for that broken batch of Sony batteries dates back from
2006. All the batteries that could have been recalled have now
been recalled, and somebody particularly interested in supporting
them can match the batteries using the old rules file, in a
user session or a separate daemon.
