When UPower would appear, or disappear, we'd get warnings like:
g_object_notify: object class 'UpDevice' has no property named 'g-name-owner'
or:
g_object_notify: object class 'UpClient' has no property named 'g-name-owner'
This was caused by the property proxying added in 7531dbd and 28438a7
being too lax about which properties it tried to proxy, which included
ones that didn't apply to the object types in question.
See https://bugs.freedesktop.org/show_bug.cgi?id=43001https://bugs.freedesktop.org/show_bug.cgi?id=102350
Export approximate battery levels that devices can use, exported by
the kernel as POWER_SUPPLY_CAPACITY_LEVEL_* values.
This avoids bizarrely accurate values showing up in UIs when we only
have ok/warning levels of accuracy in some cases.
https://bugs.freedesktop.org/show_bug.cgi?id=100359
Those levels will not be used to cover warning levels, but approximate
battery levels that devices can use, exported by the kernel as
POWER_SUPPLY_CAPACITY_LEVEL_* values.
See linux/power_supply.h
https://bugs.freedesktop.org/show_bug.cgi?id=100359
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.
