Now that we have tablet support in wayland, we can kind of honor
that in the places we're interested. The inverse (looking up the
GdkDevices that a single GsdDevice represents) is unneeded.
Similar to CcWacomDevice vs GsdWacomDevice, CcWacomTool is meant to
replace the GsdWacomStylus object. There is a substantial difference
between these two objects, CcWacomTool offers constructor methods,
it expects the caller to maintain lifetime otherwise. while
GsdWacomStylus objects creation was rather fixed (GsdWacomDevice
created all possible styli on initialization). This latter model
doesn't help us use all the possibilities wrt wayland configurability.
This is a vast oversimplification of GsdWacomDevice. This one
has code that is largely unnecessary here (mostly devised for g-s-d),
plus it will be even eventually removed from g-s-d (the functionality
is moving into compositor domain), so the code sharing argument
remains pretty weak.
So, CcWacomDevice is thought to take over, just offering the basic
API we after all need in the gnome-control-center side.
Now that gnome-session's acceleration helper can print the renderer
under Wayland, launch it locally. We need to launch it locally as
Wayland is not available at the time gnome-session would launch the
helper, as there's no Wayland compositor yet.
Note that this code expects the gnome-session helper scripts to live
in $libexecdir, but distributions can use
--with-gnome-session-libexecdir=DIR to pass another one.
https://bugzilla.gnome.org/show_bug.cgi?id=756914
We need to check the interlaced flag too when preselecting the current
resolution in the combo box since we now have separate entries for
interlaced and regular resolutions of the same size.
https://bugzilla.gnome.org/show_bug.cgi?id=772708
If no items are added to the GVariantBuilder, g_variant_builder_close()
would throw a critical, g_variant_builder_end() would throw a
segmentation fault.
As this can only happen when there are no items added to the output_ids
hashtable, this should only happen if there are no displays known to
libgnome-desktop (and therefore mutter).
See https://bugzilla.redhat.com/show_bug.cgi?id=1280075https://bugzilla.gnome.org/show_bug.cgi?id=771875
This patch introduces a change to the Lock/Unlock logic. From now
on, unlocking the panel causes the "Lock" button to turn into the
"Add Printer" button.
https://bugzilla.gnome.org/show_bug.cgi?id=767600
This toggle is always set to off when the panel is opened. We should
check whether it's on or not when opening the panel. Currently we are
only subscribed to changes, so we don't check the wifi state until it's
toggled on or off after the panel has been opened the first time.
https://bugzilla.gnome.org/show_bug.cgi?id=771564
They should probably have been unsigned integers, but they're not, so
warn if they are. The rest of the code handles negative values as if
they were 0.
https://bugzilla.gnome.org/show_bug.cgi?id=771542
From https://bugzilla.gnome.org/show_bug.cgi?id=765969 as explained by
Dan Winship:
"
libnm-util/libnm-glib had a buggy data model, which nm-connection-editor
(and then gnome-control-center) copied, in which each manually-configured
IP address has an associated gateway address. In reality, NM always just
took the first non-empty gateway value from the address array, and
completely ignored any other gateway values.
libnm represents this more accurately, by having a single gateway
value which is separate from the address array. Ideally, the editors should
show it this way as well (eg, like nmtui does). Failing that, it would
be nice to at least make it so that only the first row in the address
table can have a non-empty gateway value.
"
We went for the second option, only showing a gateway entry for the
first address in the list.
This isn't related to route-specific gateway addresses.
https://bugzilla.gnome.org/show_bug.cgi?id=765969
