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.
This should significantly simplify these panels, by not forcing
them to override GObject.constructed all the time. Most panels
were quite straightfoward.
Ignored in Meson < 0.60.0, deprecated since 0.60.1 and fatal since 0.61.0.
panels/applications/meson.build:10:5: ERROR: Function does not take positional arguments.
panels/background/meson.build:10:5: ERROR: Function does not take positional arguments.
panels/camera/meson.build:10:5: ERROR: Function does not take positional arguments.
[...]
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.
Running the helper will launch gnome-control-center with a mocked Wacom
Cintiq tablet through umockdev when one isn't present or easily available.
The Cintiq was selected as it will trigger showing all the different
buttons Wacom tablets can make the panel spawn.
It’s possible for `gdk_cursor_new_for_display()` to return `NULL`. It’s
OK to pass `NULL` to `gdk_window_set_cursor()`, but not OK to then unref
it.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
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.
We generally use tool ID 0 if the ID is actually unknown, libwacom however
assigns 0xfffff to such device. Make it sure we find the "Generic Pen"
stylus description in that case.
Make the panel class provide a cancellable that will be cancelled when the panel
is destroyed. Panel implementations can use this and not have to mangage the
cancellable themselves. Consolidate cases where panels had multiple cancellables
that were all being used for this behaviour.
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
The button/popover are meaningless if there's no device to test with. Set
it inactive (so the popover hides if visible) and set insensitive if no
devices are found.
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
This used to be done only if the stylus was "brand new", because pages for
previously known styli are added when the tablet is detected/plugged. There
are however situations where this may break: eg. the stylus was previously
known through a tablet that is not plugged ATM. The tool is however "not
new" so no UI is added for it.
We should try to add the stylus invariably on proximity, add_stylus_page()
ensures there is only one page per tool anyway.
Closes: https://gitlab.gnome.org/GNOME/gnome-control-center/issues/315
When the wacom driver handles the touch device, we get a tool id of 0x3. Let's
ignore that because we don't need a tool for the touch node.
Ideally we should be able to rely on the GDK tool type but that one is always
GDK_DEVICE_TOOL_TYPE_UNKNOWN see
https://gitlab.gnome.org/GNOME/gtk/merge_requests/453
A GTK bug (also fixed in that MR) prevents the tool id from updating.
Until that GTK bug is fixed the pen will only be detected if it is the first
event from this physical device. If the touch node sends an event before the
pen, the pen won't be detected.
When we bring a generic pen (serial 0) into proximity, the tool is initialized
as "generic" and mapped to the current tablet. This is then written out into
the keyfile, so we end up with something like:
[056a:00d1]
Styli=generic;
On the next g-c-c start the generic pen is pre-loaded from the keyfile but not
yet associated with the tablet. When the pen gets into proximity the
association was handled like a completely new pen, thus triggering a key file
entry again. Eventually, our styli list looked like this:
[056a:00d1]
Styli=generic;generic;generic;generic;generic;generic;
Fix this by remembering whether we freshly initialized the tool or whether it
was already known. Since we can only have one generic tool per tablet (because
we wouldn't notice the difference between two physical tools) we just skip the
write of the keyfile.
Fixes#313
The xf86-input-wacom driver doesn't use 0 for tools that do not have an id or
serials. Serials default to 1, and the tool id is either 0x2 for stylus or 0xa
for eraser, see xf86WacomDefs.h, the defines for STYLUS_DEVICE_ID and
ERASER_DEVICE_ID.
libwacom uses 0xfffff and 0xffffe for the generic pens and all the lookup code
we have in the panel is designed for a serial/tool id of 0. So let's just map
the wacom driver IDs to 0 at the only transition point between Gdk and our
panel.
No devices with serials 0 or hw ids 2/10 exist, so this shouldn't have side
effects. This only affects X + xf86-input-wacom.
