UPower 1.0 API changes

[Bastien Nocera]

On Mon, 2013-10-21 at 11:26 +0100, Iain Lane wrote:
> Hi,
> 
> On Thu, Oct 17, 2013 at 03:44:45PM +0200, Bastien Nocera wrote:
> > Heya,
> > […] 
> > libupower-glib
> > --------------
> > […] 
> > Removed functions:
> > - up_client_get_properties_sync()
> > - up_client_enumerate_devices_sync()
> > - up_client_get_on_low_battery() (use the "warning-level" property on
> > the DisplayDevice object instead)
> > […]
> > - All of the QoS API
> > 
> > Removed signals:
> > […]
> > - changed (both UpClient and UpDevice), device-changed (connect to the
> > "notify" signal for the properties that interest you instead)
> > 
> > Changed signal:
> > - device-removed now sends an object path, not a device (as we do not
> > keep an internal list of devices on the client side, to reduce wake-ups)
> > 
> > D-Bus service
> > -------------
> > 
> > The D-Bus service changes pretty much match the libupower-glib API
> > changes. I invite you to read the included API documentation.
> > […]
> 
> Hmm, some of these are a bit worrying. We've known about
> Suspend/Hibernate being dropped for some time, as they were announced.
> This allowed us in Ubuntu to try and hunt down any consumers and port
> them to using logind.
> 
> The rest, though, are a surprise—especially the soft interface changes
> like signals and changes to the DBus API.

The "Port to GDBus" bug has been opened since February 2012. The
interface changes are, amongst other things, a response to that.

>  Could they not stick around
> for at least one release as deprecated interface to give consumers (and
> distributions) a chance to port away from them more gently?

Keeping the deprecated interfaces, especially the signal emission, would
nullify any benefits we might have had by reducing signal emissions.
More wakeups, less targeted properties changes.

>  The rest of
> the improvements are great and much needed so it'd be a shame to have to
> stick on 0.9.

In the GNOME stack, we had 3 users in the shell stack
(gnome-settings-daemon, gnome-control-center, and gnome-shell), and 2
session daemons (tracker and telepathy). They've all been ported
already, with a minimal amount of work, and a huge win in terms of
complexity on the client side (especially the composite batteries).

So before saying "bring back the old interfaces", I think you should go
through your users of the interface (whether D-Bus or through the
library) and look at what the porting would involve. I doubt you have as
many users of the interface as you think you do (unless you intend on
porting every desktop environment yourself, obviously).

Cheers