This puts stylus/pad tracking on 2 separate levels. The CcWacomPanel
will look for styli, and treat them as "device leaders", adding a
CcWacomPage for them.
The CcWacomPage will then track the related pad, and update the
"Map buttons..." action visibility according to it.
This simplifies tablet page creation (eg. have it completed in one
step), and decouples the device grouping logic from CcWacomPanel,
which will be useful in future commits.
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.
Tablets have not always an eraser (most of the generic tablets like Huion,
UC-Logic, etc... don't). We should not reject such tablets.
Commit 54849a9 (wacom: Only the stylus and eraser tools need to exist)
mentioned that we were not sure about eraser, and I think we should not
assume one either.
To do so, we simply ignore the eraser xinput node and rely on
libwacom to actually provide the eraser information.
If the stylus does not have the eraser tip, we may fall in the
LAYOUT_OTHER case. We have a picture of a generic Wacom pen with an
eraser, and the leaders linking the widget to the picture are scrambled.
To prevent that, gray out the eraser pressure slider so that we do not
break the layout.
https://bugzilla.gnome.org/show_bug.cgi?id=746117
The device_added_cb is called once for each tool added. The wacom driver
hotplugs tools in the order stylus, eraser, cursor, pad.
update_current_page will add a new page once a tablet has stylus and
eraser, before cursor and pad exist. priv->pad is thus always NULL,
causing, cc_wacom_page's update_tablet_ui to remove the "Map Buttons..."
button for any device.
Change the code to update the tool list for every new tool we get,
merely triggering the visibility of the button instead of destroying it
completely.
https://bugzilla.gnome.org/show_bug.cgi?id=672691
