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.
We don't need to track them much specifically, as we delegate pad
button mapping UI on GNOME Shell. It is however possible to have
tablets with 0 to N pads (upper bound within sanity = 2), so we
must at least reflect that in the "Map Buttons..." button visibility.
This distinction is most important for the combination of EKR plus
Cintiq 27QHD, as this is a pad-less tablet, for which we wouldn't
usually show the "Map buttons..." action.
https://gitlab.gnome.org/GNOME/gnome-control-center/issues/415
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.
A little above in the function, we update the page UI, maybe destroying
the bits that allow decoupling display-attached tablets from their display.
Later on, we unconditionally update its GtkSwitch.
This can't bode well on tablets where the widget was already destroyed.
This is useful for 2 cases:
- Tablet-input-driven setups where it makes sense to be able to quickly
reach other monitors with the tablet.
- (Hopefully a minority) Cases where our display mapping heuristics go
wrong and tablet gets assigned to a wrong monitor.
Closes: https://gitlab.gnome.org/GNOME/gnome-control-center/issues/239
Looks more natural this way. All buttons and links have been moved
into the main grid so this is possible. The links additionally had
to be removed all the padding so they actually align visually.
Closes: https://gitlab.gnome.org/GNOME/gnome-control-center/issues/238
Commit cf408c27b0 changed how the values stored in the "area" key were
calculated in order be compatible with its updated schema. Unfortunately,
it overlooked the fact that updated schema also changed the order of the
values from "left, top, right, bottom" to "left, right, top, bottom".
Because of this, corrections intended to be applied to the top and right
screen edges were swapped. This can cause a noticible cursor offset to
occur after finishing calibration.
https://bugzilla.gnome.org/show_bug.cgi?id=784009
The calibration utility was modified in cf408c27b0 to return unitless
padding measurements instead of axis values for storage in gsettings.
Unfortunately, the code still assumes in some places that it is working
with axes rather than paddings. This causes subtle math errors that
result in undesired cursor offsets after the calibration is applied.
Fortunately, this can be simplified, since tablet area is always reset
to the default state before starting calibration, we are sure that the
value will remain constant. Since both axes are in the same 0..1 scale,
calibration code doesn't need to swap X/Y back and forth to calculate
each axis scale.
Additionally, the code to get the calibrated axis values has been moved
into its own function along with a new function that returns padding
values suitable for consumption by g-c-c. All calculations are performed
internally in the 0..1 range.
https://bugzilla.gnome.org/show_bug.cgi?id=784009
Co-Authored-By: Carlos Garnacho <carlosg@gnome.org>
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.
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
We shouldn't be using the old calibration values to create the
new ones, so reset the "area" settings before starting a new
calibration, and re-apply the saved calibration if the calibration
is cancelled or fails.
https://bugzilla.gnome.org/show_bug.cgi?id=707784
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
Action type comes from GSettings and may have been changed
to some invalid value, causing a segmentation fault in
control-center if the value is larger than the known action
types. This can also occur when downgrading from a version
with more possible actions.
Adds a sanity check to verify the given action type value
is within the bounds of the known action types.
https://bugzilla.gnome.org/show_bug.cgi?id=689265
