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.
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.
So the panel implementations will be able to set a custom widget
in the shell headerbar. It defaults to NULL, so by default panels
set the plain label with the panel title.
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
