#268 Setting default values to tablet pad's buttons

[Jehan]

Right now, the tablet pad come very "bare". All the buttons have no functions associated to them.

I may understand for the ones with no labels, or labelled generically FN1/FN2. But somes for instance have arrows (on a Bamboo for instance, one button left arrown and one button right arrow), which I would definitely map by default to XF86XK_Back and XF86XK_Forward respectively.

Similarly I would map the wheel by default to XF86XK_ZoomIn and XF86XK_ZoomOut, which is the default behavior most expected for the wheel.

Up to the user to remap these later if one has special needs (like using the wheel for scroll purpose instead), and for these use xsetwacom or some other GUI of one's choice, but at least it would be great to have acceptable default for a better user experience.

[Jason Gerecke]

Absent any configuration being done by you or your desktop environment, or your distro, the buttons on Bamboo tablets should have sane defaults (i.e. act as left, right, back, and forward keys as you suggest). Similarly, the wheels should by default send scroll-up and scroll-down events.

Are you using GNOME (or Unity on Ubuntu) by any chance? They replace our mappings with their own, which by default perform no action. If you have an Intuos or Cintiq, you'll probably want to use their gnome-control-center utility to set up the buttons. Their utility has issues with Bamboo tablets though. See also [bugs:#244] and [bugs:#266].

[Jehan]

My current distro is Linux Mint 17 (Mint is based off an Ubuntu, so if they didn't do anything specific for tablets, they would use Ubuntu defaults, I guess). And my desktop is Cinammon (itself based off GNOME 2, if not mistaken).

For GNOME, would you have some references (bug IDs, or mailing list discussion for instance) where they discussed this? I assume that's a conscious choice, but I would like to know why, and open a report (if there is not one already, but I could not find any). I personally find it non-user friendly.

I am a GIMP developer, so I am close to the GNOME project too and would like to revert this kind of default to saner ones.
Also where are these defaults set (by you and by the GNOME/distribution projects)? This would allow me to push a patch forward, which could accelerate things.
Thanks.

[Jason Gerecke]

Apologies for the delay in replying.

I don't believe a conscious choice was made by GNOME to leave the buttons unmapped. Rather, their developers have tended to focus on the high-end Intuos and Cintiq tablets that don't really have labeled buttons. In my discussions, I haven't gotten the feeling that they would be against the idea of providing defaults where they make sense (e.g. "back" for a button with a left-arrow icon).

You might run into some difficulty, however, since GNOME does not like the idea of using keyboard (e.g. ALT+LEFT) or mouse (e.g. button 8) events for this kind of thing unless absolutely necessary. Discussion on this is all off-list unfortunately, though there are hints of it at the Tablet panel's design page (see the "Comments" section) and their bug #686782.

Patches would likely need to be made for both gnome-settings-daemon (which is responsible for configuring the tablet under GNOME) and libwacom (which describes the capabilities of tablets well enough for gnome-settings-daemon and gnome-control-center to do their jobs).

[Jehan]

You might run into some difficulty, however, since GNOME does not like the idea of using keyboard (e.g. ALT+LEFT) or mouse (e.g. button 8) events for this kind of thing unless absolutely necessary.

And I would totally agree with them. Right now to zoom, I need to map the scrolling wheels to +/- (or ctrl +/-) for most apps (most common default), but I think that's completely shitty. I think we must use semantics keys when possible, like the XF86 ZoomIn/Out and Back/Forward, etc. (and indeed not alt-left/right nor mouse button).

But then there is the problem of egg and chicken: if no apps support these keys, mapping your tablet to this is useless (same as no mapping).
This is the reason why I made a patch for Firefox to support ZoomIn/Out (which is on the way to get pushed on the main tree. And Firefox already supports Back/Forward keysyms), and I made one for GIMP too (though I may need a little more time to rethink this patch though).

I chose Firefox because browsers are nowaydays the software where most people spent most of their time, and obviously GIMP because that's a software that people with tablet would likely use. So with these, I believe the egg/chicken situation will be fixed. :-)

[Ping Cheng]

Not a driver issue