We read the window-scale-factor gsettings and propagate to gdk, including doing
auto-detection if the setting is 0.

Additionally, we scale the old Xft.DPI setting by the window scale so that old
applications get a decent size on very high dpi monitors, plus we report the
unscaled dpi so that window scale aware apps (like gtk) can avoid this
dpi scaling.

A property is easier for clients to manage, as they'll automatically
get new PropertiesChanged signals when the value changes, and with
GDBus bindings, properties are cached field lookups that don't require
asynchronous access.

If there are any errors when fetching the new brightness, the value
-1 is returned, so the interface has been modified slightly to support
signed values.

Also adapt the color and media-keys plugins to the new interface.

https://bugzilla.gnome.org/show_bug.cgi?id=698754

We want to add properties on the Screen iface, so remove this.

https://bugzilla.gnome.org/show_bug.cgi?id=698754

So that we use upower's knowledge of that value instead of making
up our own. This fixes the test_action_critical_battery test failing.

https://bugzilla.gnome.org/show_bug.cgi?id=700913

Jasper St. Pierre authored May 22, 2013 and Bastien Nocera committed Jun 17, 2013

With one battery, the composite device should report what we want as
well, so this shouldn't see any major changes in most cases. The reason
this is wanted is so that when the device is charging or fully charged,
we'll get the composite device as well, rather than throwing an error.

https://bugzilla.gnome.org/show_bug.cgi?id=700913

Jasper St. Pierre authored Jun 10, 2013 and Bastien Nocera committed Jun 17, 2013

And ensure that it returns -1 when we have no devices in the composite
device.

https://bugzilla.gnome.org/show_bug.cgi?id=700913

Jasper St. Pierre authored Jun 10, 2013 and Bastien Nocera committed Jun 17, 2013

https://bugzilla.gnome.org/show_bug.cgi?id=700913

Jasper St. Pierre authored Jun 10, 2013 and Bastien Nocera committed Jun 17, 2013

The code before was a tad too generic..

https://bugzilla.gnome.org/show_bug.cgi?id=700913

Jasper St. Pierre authored Jun 10, 2013 and Bastien Nocera committed Jun 17, 2013

This was always a bit unnecessary, as it was only called with a
device kind of BATTERY.

https://bugzilla.gnome.org/show_bug.cgi?id=700913

Jasper St. Pierre authored Jun 10, 2013 and Bastien Nocera committed Jun 17, 2013

In the scenario when we only have one battery, we short-circuit and
use that instead of creating a composite device. We want to always
expose the composite device as an API, so never do that.

https://bugzilla.gnome.org/show_bug.cgi?id=700913

We were using the energy, energy_rate and energy_full from
the last read battery when creating the composite device, instead
of the aggregated value.

Replace the bash-only substitution with an sh-compatible version.

https://bugzilla.gnome.org/show_bug.cgi?id=701322

We were trying to remove a comma instead of a single-quote.

https://bugzilla.gnome.org/show_bug.cgi?id=701322

When replacing an existing notification with a more up-to-date one,
we were closing the existing notification, and creating a new one in its
place. As, to clean up when a notification is dismissed by hand, we hook
up to the "closed" signal, we ended up zero'ing the pointer to the just
shown notification and making it impossible to remove later.

eg.
- 1st notification created
- updated state comes in
- notify_close() called
- notification pointer is replaced with newer notification
- main loop returns
- "closed" signal is received for the 1st notification (ah!)
- original notification is unref'ed, and its location is zero'd
  by weak pointer call.

That location is that of the new notification as well.

https://bugzilla.gnome.org/show_bug.cgi?id=702047

Pressing the button will show the GNOME Control Center at the device's
configuration page.
It also shows the pointer when the movement was performed by a mouse type
device, hiding it again after a little while.

https://bugzilla.gnome.org/show_bug.cgi?id=692817

In particular, we can't get the locale value out of GSettings
in order to set LC_PAPER etc, since calling into GSettings
initializes the dconf backend which in turn uses gdbus, which
starts a worker thread.

As a simple workaround, set up the locale environment in
a small wrapper script that then exec's the g-s-d binary.
https://bugzilla.gnome.org/show_bug.cgi?id=701322

It was using the device as first argument and the action as the
second but this has been changed in g-c-c and is the other way
around.

Richard Hughes authored Jan 14, 2013 and Bastien Nocera committed Jun 05, 2013

With an unfinished "yum-complete-transaction to run"[1],
the updates plugin started filling the message tray with "Software
Updates Failed" errors.

This patch removes the previous notification when adding a new one.

https://bugzilla.gnome.org/show_bug.cgi?id=691627

https://bugzilla.gnome.org/show_bug.cgi?id=701249

We don't want to get DBus requests until we applied all settings at
least once.

https://bugzilla.gnome.org/show_bug.cgi?id=701055

So that we can call register_manager_dbus() from localed_proxy_ready()
in the next commit.

https://bugzilla.gnome.org/show_bug.cgi?id=701055