This needs to have a design first before we can implement this.

The functionality itself is interesting, but what actions do we want to offer users? Undo/Redo? Other things?

Would those other actions be application specific? And if that were the case, why wouldn't we leave it to applications to implement?

Do you have examples of how this is implemented in other OSes/desktops?

there are two different approaches for this. The simple approach is a UI similar to the keyboard shortcuts UI. User clicks on the button they want to map, then presses a key sequence. This does not have any restrictions on what actions.

The better approach imo would be to get common actions into the toolkit. Many applications support undo/redo, copy/paste, save, zoom, etc. These could be exposed through a different event type and mapped inside the toolkit.

Of course there is also the option of just hoping every application will be able to provide custom button actions, but that's inconsistent (each app needs its own UI) and I don't wager my bets that that'll work anytime soon.

In regards to application-specific settings, wouldn't be the domain of GTK's InputDialog? It appears to be application specific, and has a section for mapping numbered "keys" (buttons?) to key presses. Of course, since InputDialog is only used by a handful of applications, it hardly addresses the issue in a truly viable way.

For desktop-wide settings, providing clicks and common keyboard shortcuts would be a good start I think. The ability to set arbitrary keyboard shortcuts would also be welcome (at least until application-specific settings work across most applications), as would other mappings provided by the Windows/Mac drivers such as open/run and display toggle.

Created attachment 200047 [details]
Screenshot of Wacom control panel under Windows with the button mapping menu open

For reference, this is how button mappings are handled under Windows. ExpressKeys have slightly different options than stylus buttons, but they're mostly all there.

i see the application-specific settings overriding the global settings. e.g. you may want button 3 in gimp be the tool selector but everywhere else it should be right-click. so the global config and the application config need to coexist.

Peter, what kind of information do we get in button events from these devices ?

they look like normal button events. If the driver is configured to send key events instead (or in addition), you'll just see normal key or button events. In the client, you can't tell if key event for 'a' was triggered by a real key or by the wacom driver sending a key event instead of button 1.

I was asking because I was pondering if the events contain enough identifying information to let us keep a mapping like 'button4 -> undo' somewhere in the desktop, and have applications consult that mapping when they interpret those events.

unfortunately not. they're just normal button events. all the mapping is done transparently in the driver.

even being normal button events, if they contain enough information for letting us show something like 'Wacom Cintiq 21 UX R5' in the button mapping ui, then an app could use that same information to look up an associated action, no ?

yes, of course. you get deviceid and (logical) button number plus modifier state of the attached master device.

what I meant in Comment #10 is that if the driver maps button X to "ctrl + z", you'll just never see a Button X event, you'll see keystrokes for ctrl and z though but on the client you can't sensibly determine whether that's a real key press or a special button mapping.

The information is available in a driver-specific property but parsing that is not a good idea for GTK imo.

But it would be possible to make the driver not do its own button -> key mapping, and instead have it send 'unmolested' button events, which we could use to look up our own client-side mapping ?

That would be possible, though (at least at the moment) it'd have to be controllable by some kind of toggle. If we were to remove mapping support from the driver entirely, it would represent a major regression for other desktop environments. On the other hand, allowing applications like xsetwacom to continue to modify the button mappings under the nose of another library is sure to cause confusion.

(In reply to comment #13)
> But it would be possible to make the driver not do its own button -> key
> mapping, and instead have it send 'unmolested' button events, which we could
> use to look up our own client-side mapping ?

of course, that's the default setup anyway. In the ideal future when users only configure through the panel, that'll just work then. Though the transition period until applications start using the mappings will be a tad painful, and you may never cover non-native applications. Still, imo the way to go.


(In reply to comment #14)
> On the other hand, allowing applications like xsetwacom to
> continue to modify the button mappings under the nose of another library is
> sure to cause confusion.

xsetwacom, xinput, synclient, xmodmap, etc. are all tools that work under the radar of GNOME already. They're the guns that you need to be careful of not pointing down towards your foot.

Was fixed in GNOME 3.4. Support for additional keys, and better application integration are separate bugs and topics.