This code is going from g-s-d, the remaining bits should be adopted
by g-c-c.

It is now entirely unused.

So it works again.

So it can be used in test-wacom

Some improvements to fit better with the new design:
- "no configured ..." page for both stylus/tablet sections
- the navigation buttons are now children of GtkRevealers, so
  size doesn't popup
- Empty placeholder in several containers have been removed.

The "area" setting has a different treatment in the gsettings-desktop-schemas
tablet schema, the 4 double values express the padding (in unitless 0..1
range) on each of the sides of the tablet. It's been done so we don't rely
on input/output units, which we might have not the luxury to access.

Besides that, the dependency on GsdWacomDevice has been cleared.

This feature now belongs in gnome-shell, not g-s-d. The D-Bus API
changed correspondingly.

We now use the CcWacomDevice API for this.

This function retrieves the GSettings pointing to the configuration
of the given button, or NULL if not found.

Uses libwacom underneath.

We now only care of pad buttons, so this code can be quite simplified.

The set of actions that can be mapped to an stylus button have been
reduced, due to inconsistent semantics in wayland.

There's much going on under the hood here:
- Styli and tablets are now in split views, as per the mockups.
- CcWacomDevice and CcWacomTool are now in use, with the subsequent
  API use changes. Moreover, using these objects means using the
  newer schemas in gsettings-desktop-schemas, so there had to be
  changes in the settings we store too.
- We now use CcTabletToolMap, plus listen to tool proximity events,
  populating the "Stylus" sub-pane with those.

This can only be used for tablets that are not display nor system
integrated (eg. intuos models). The mapping of tablets with a builtin
display remain in g-s-d/GsdDeviceMapper.

In the wayland tablet input model, compositor and clients may
recognize the different physical styli in use, even if those are
used across compatible tablets.

This object is intended to be used as a persistent memory of
which stylus was used with which tablet. So you 1) can associate
tools and devices when such combination happens, and 2) query the
styli that were previously used with a tablet when it is detected/
plugged.

These associations are stored in two keyfiles in
~/.cache/gnome-control-center/wacom/, one for tablets and other
for styli.

So we can recognize pad devices.

Now that we have tablet support in wayland, we can kind of honor
that in the places we're interested.

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.

A popover with a CcDrawingArea appears in that case.

This is a testing drawing widget that can be used to the a feeling
of changes to stylus settings.

If the current panel requests setting a custom widget, honor that
and place those in the headerbar.

If the current panel requests setting a custom widget, honor that
and place those in the headerbar.

So the panel implementations will be able to set a custom widget
in the shell headerbar. It defaults to NULL, so by default headerbars
set the plain label with the panel title.

Now that there's only one type to be added (VPNs).

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

We still offered to add Bond, Team, Bridge and VLAN connections even
though we don't support them any more. Remove the first page as we only
offer to add VPN connections.

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

The VPN editor API changed as well.

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

The listing of VPN plugins was done using the nm-glib API instead of the
new libnm 1.2 one.

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

According to the mockups at
https://wiki.gnome.org/Design/SystemSettings/UserAccounts

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

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

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

Martin Hatina authored Jun 20, 2016 and Marek Kašík committed Jun 21, 2016

Use PpPrinter class for renaming printer asynchronously.

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

Martin Hatina authored Jun 20, 2016 and Marek Kašík committed Jun 21, 2016

Introduce new class that represents printer.

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