When the "Automatic" mapping is chosen for a display-attached tablet device,
Mutter is in charge of applying the heuristics to map the tablet device to
its most likely attached display.
When that happens, the Wacom panel does not know better (or anything)
to show the calibration UI than picking a GdkMonitor and hoping for the
best.
To improve this situation, Mutter has been added a D-Bus interface so it
is possible to query it for the output that a tablet device is mapped to.
This commit adds the support for this interface, so that the Wacom panel
does know to pick the right GdkMonitor to fullscreen the calibration UI on.
Many part of this commit were made by Carlos
Garnacho <carlosg@gnome.org>
WIP wacom: Port to GTK4
Lots of stuff missing and probably broken.
wacom: Port CcDrawingArea input to gestures
We have a handy GtkGestureStylus to use here, which avoids direct
handling of GdkEvents.
wacom: Update current stylus tracking to GtkGestureStylus
Use the ::proximity signal to notice when we are being hovered with
a tablet stylus, and look up the tool from there.
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.
Same dog, different collar. The UI has been ported 1:1 to GTK+, using
GtkBuilder, CSS and event controllers fairly reduced the amount of code
needed for this.
It also allows us to stop initializing clutter-gtk across the several
executables.
We should be pairing gtk_window_get_size with
gtk_window_set_default_size to avoid inconsistencies between the size
reading and setting code. eg., in recent GTK+ versions,
gtk_window_get_size and gtk_widget_set_size_request differ in their
interpretation of the CSD chrome.
However, gtk_window_set_default_size didn't work with non-resizable
GtkWindows, until now.
https://bugzilla.gnome.org/show_bug.cgi?id=762548
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
Since GTK+ commit 05b1ea84b, this hint is used in GtkNotebook to add
a GTK_STYLE_CLASS_FRAME when rendering the notebook frame, so the theme
renders those frame-alike. As it's not what we want for the wacom panel,
set show-border to FALSE on all GtkNotebooks.
https://bugzilla.gnome.org/show_bug.cgi?id=710709
The name of the file was also changed to calibratorgui.c/h to avoid
it being inconsistent, this way it is no longer dependent on the
the technology.
https://bugzilla.gnome.org/show_bug.cgi?id=667797
