Improve display of Wacom pad actions for directional controls (rings / strips)
Feature summary
The Wacom pad OSD allows users to view and change the actions that will be executed when the pad controls are used. The OSD displays an SVG layout file that represents where the controls are and includes information on where to draw labels. Some control types (buttons) have a single label associated with them, while others are directional (rings, strips) and have two labels -- one for each direction (CW/CCW, up/down).
I find the current OSD implementation difficult to understand when it comes to directional controls. While these controls have two independent labels, the OSD displays the same text on each label. I am forced to decipher something like "↻ b / ↺ a" rather than simply seeing "b" and "a" labels next to the clockwise and counter-clockwise controls.
How would you like it to work
I would like the pad OSD to display direction-specific labels for the direction-specific controls. The user would see a label next to the e.g. "clockwise" directional indicator and be able to immediately decipher that that single action will occur when the control is used in a clockwise motion. See the example screenshot below.
Relevant links, screenshots, screencasts etc.
The pad OSD already saves directional information when creating labels and reads it back when filling in their text. Unfortunately, directional information can't be provided to the mutter function which generates labels. If directional information were plumbed through to where ring and strip labels are generated, we would not need to generate a single label for both directions.
Related to this, I notice that the Wayland protocol items zwp_tablet_pad_ring_v2::set_feedback and zwp_tablet_pad_strip_v2::set_feedback do not provide a way for clients to specify directionality when setting labels. To be clear: this limitation does not block the implementation of the requested feature for compositor-defined labels (since they aren't set through the limited Wayland protocol). It is, however, something I should bring up separately with the protocol developers so applications can set the labels individually just like the compositor.
/cc @carlosg