GitLab

This reverts commit 11c0be54.

Wrong keybinding.

before 34395459, apply_all_settings()
and then apply_numlock() would sync up the numlock LED on a newly
hotplugged device.
34395459 removed that call, so devices
now come up with the numlock LED off even when the numlock is on, and a
subsequent state change will wrongly toggle it, i.e. LED off when numlock
is on, LED on when numlock is off.

This should really be fixed in the xserver but it's unlikely to happen,
restoring this patch in gnome-settings-daemon seems the simplest solution
for now.

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

When sharing the same home directory over NFS, it might be convenient
to share device configurations as well, so that the "Wacom Intuos X" on
machine A has the same configuration as "Wacom Intuos X" on machine B
for that user.

The work-around makes the machine-id be all zeroes when
~/.config/gnome-settings-daemon/no-per-machine-config
and as such, should not be applied during a running GNOME session.

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

This will make GTK+ dialogs have headerbars.

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

We stopped using them in commit
87d63535.

There is no replacement for this icon, so better is removing the icon from the
button.

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

Starting GTK 3.10 GTK_STOCK items are deprecated in favor of defined labels or
standard icon names.

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

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

Super+S conflicts with the "panel main menu" shortcut.

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

This reverts commit f20df990.

So the user is notified when plugging a brand new tablet, or a
previously known one that's maybe miscalibrated on the current
set-up.

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

So gsd_wacom_device_get_device_type() isn't called multiple times.

Since commit 5bbe63ff, the power plugin DBus interface doesn't have the
properties that media-keys plugin expects here. So keep an UPower display
device to fetch icon/percentage for the OSD.

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

Listen for changes in the last calibration resolution, so if the user did the
calibration directly through g-c-c instead of the notification, the notification
is dismissed from the notification area.

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

All information around calibration notifications is now in a separate
struct, set as GObject data on the GsdWacomDevice. On calibration checks,
each device updates its notication as required. This fixes:

1) The notification being possibly not shown if multiple in-screen devices
   are present. If the resolution changes on one monitor, but the device on
   the other monitor is checked last, the notification was then closed/removed.

2) Older but still valid notifications disappearing if a second device needs
   calibration.

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

This may happen in the case gnome-shell is not running when g-s-d starts
up. This fixes a crash in such situation, as priv->rr_screen was assumed
to exist soon after.

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

GdkDevices aint' GsdWacomDevices, so lookup the latter from the former.

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

The idle was being removed, but the source ID was left != 0, so on
shutdown it'd cause warnings.

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

Instead of just FALSE, this is a cosmetic change.

Use #include <X11/XAtom.h> instead of having </usr/include/X11/XAtom.h>
hardcoded.

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

The check to inhibit the lid close action when there's external monitors was
quitting after the first run, even though it announces it will check again later.

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

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

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

If we don't have this #include, we get
-Wimplicit-function-declaration.

The offline updates status file needs to be around for the failed text and also
if we're using gnome-software to review the changed updates. We're already
removing it in the callback even for the non-gnome-software case.

It lives in the Debian and Fedora packages at least, and I stopped
digging through downstream package crap after that.  From the mailing
list discussion, yeah, while Marcel has a point, in practice, console
users can shut down the machine too...

And many downstreams ship NetworkManager with permissions such that
the user can control system networking to a large degree.

Given that, let's just pull this upstream, anyone who doesn't want it
can work on engineering something else (which is likely making
NetworkManager be a proxy).

The *real* reason I'm doing this is because it avoids librfkill-glib
as used by gnome-shell spewing a g_warning() on start.

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

Since in Continuous, the gdbus-codegen for Shell ends up there.

This helps having a clue of which monitor got mapped to the device, other than
waving the pen to check where the pointer ends up. Now gnome-shell is requested
to show an OSD on the monitor the device gets mapped to.

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