Pens with an integrated eraser share the serial number with the
corresponding pen but differ in the tool ID. libwacom provides a
"paired_id" mapping to look up one from the other.
If the user brings the eraser into proximity the very first time the
tool is seen, the eraser's tool ID is stored in the keyfile instead of
the associated stylus id. This leads to otherwise wrong behavior since
erasers share the serial number with the stylus but don't have any
buttons, don't have any erasers themselves, etc.
Fix this by looking up a matching stylus when we see an eraser. This
effectively filters our CcWacomTool to always be the pen, which is an
inadvertent assumption anyway.
The overwhelmingly vast majority of users will never see anything else
than a "Standard" (i.e. pen-shaped) stylus. And there's a mismatch
between e.g. the Pro Pen 3 being labeled as "Standard stylus" when users
spent money on getting a Pro pen.
Let's drop the "Standard" prefix, it adds nothing in this context.
Now that our first and last configuration points are 0/100 and 100/0
respectively, we can simplify the calculation a bit. Doubly so because
p2 is just a mirror of p1.
That with extending the slider range to 200 means we get a value for
each integer combination on our pressurecurves - which in turn means
that for any of our generated curves we get a slider value return.
Our previously hardcoded pressurecurves follow a predictable
pattern so we can generate the value on-the-fly based on that pattern.
The slider now uses a range of 100 (integer) values and calculates the
matching pressure curve based on that. The actual pressure curve remains
the same for previous values.
However, the functions are lossy thanks to CLAMP() so figuring out
a slider position from points requires heuristics: for each of the four
coordinates we calculate a slider value. Then we calculate the points
for that slider value and if those calculated points match ours then we
have a winner.
There's only one device like this that we support so we might as well
use its name as-is instead of a more confusing "External Pad device"
which isn't very descriptive unless you work with tablets and know what
a "pad" is in this context.
Anyone who owns this device will have bought it under the name
ExpressKey remote.
Fixes https://gitlab.gnome.org/GNOME/gnome-control-center/-/issues/2044
The method gtk_widget_translate_coordinates is deprecated in gtk 4.12.
Use a new method gtk_widget_compute_point instead.
general: Apply suggestions graphene point
Meson extracts them by itself and add them as dependencies for the target.
It means one less location to keep track of files, and a lot less boilerplate
around the meson files
The `X-GNOME-Bugzilla-*` entries were for use by bug-buddy, a GNOME 2
technology that's been gone for over a decade. These entries are
obsolete and can be removed from all desktop files.
The `X-GNOME-Settings-Panel` entry is also obsolete as far as I can
tell and only these panels had it in their desktop file: notifications,
sharing, sound and user-accounts. These entries can also be removed.
After removing the `X-GNOME-Bugzilla-*` entries, the desktop files have
no more variables in them. The meson `configure_file` step is therefor
pointless—there are no variables to configure. As such the
`*.desktop.in.in` files are renamed to `*.desktop.in` to reflect this
and `meson.build` files are modified to remove `configure_file` step.
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.
If you did not know the Wacom Express Key Remote (or EKR for short),
let me introduce it to you:
https://estore.wacom.com/media/catalog/product/cache/fb4143a007ae6439deba9b18afd745f2/a/c/ack-411050_main_2.jpg
This is a hand-sized standalone pad device, meant to be used together
with drawing tablets, providing additional buttons and a touch sensitive
ring that can be mapped to actions and keypresses.
These pads were so far handled in GNOME, but in a very subtle manner.
As the EKR is implicitly paired to a tablet, it was possible to map
EKR buttons from the paired tablet once the pad OSD UI from GNOME
Shell was shown.
As this device basically just needs a "Map buttons" action to
configure it, it just didn't sit well in the older Settings UI,
it would get a separate page with just a lone button in there. So
its support has been kind of an easter egg so far.
But the new UI can indeed accomodate better a device that is neither
tablet nor stylus, and has few options. This commit adds the EKR
as a separate AdwPreferencesGroup.
This went mistakenly missing in the recent UI updates. Since this
panel is still accessible through search despite tablet availability,
we should have a proper empty state view when moving to the panel
with no tablets available.
Fixes: https://gitlab.gnome.org/GNOME/gnome-control-center/-/issues/1684
There is now the header-suffix property that makes it possible to add
tablet/stylus icons besides the title/description, so we can simply
use this widget.
