[RFC DRAFT] graphics tablet protocol extension

[Bill Spitzak]

On 09/20/2013 03:35 AM, Peter Hutterer wrote:

> * focus handling for the stylus is easy. focus handling for the buttons on
>    the pad isn't. they could technically be focused elsewhere, like a
>    keyboard focus. some buttons are definitely stylus based (BTN_STYLUS,
>    BTN_STYLUS2, etc.) so should go where the stylus is. Should look at what
>    Win/OSX do here.

I tried both Windows 7 and OS/X with a Wacom Intuos3 6x8.

The buttons act precisely like whatever they are emulating. They can be 
set to be a set of modifier keys, or a single mouse button click, or a 
sequence of keystrokes with modifiers, and the result is exactly as 
though I quickly hit the same things on the main keyboard and mouse.

If a button sends keystrokes then they go to the application with the 
keyboard focus even if the mouse is pointing somewhere else.

If they send a shift modifier then they cause keys typed on the keyboard 
to be uppercase.

Setting them to clicks causes the clicks to go to the application under 
the mouse cursor, activating those applications. This is more apparent 
under Windows where the first click in an un-activated app is still 
handled, on OS/X it just activates it and throws away the click (I 
believe Cocoa apps can see this click, but all ignore it to match OS/X 
UI guidelines).

On Windows, by using Alt+Tab, I was able to make a button type into two 
different applications!

Note that both platforms had a method to make all the button assignments 
depend on the current application.

There are also two vertical strips (just really small pads) next to the 
buttons. They may be limited to detecting the vertical position of the 
pen, but I would not be suprised if they are in fact more of the main 
tablet area and can pick up pressure and tilt and some horizontal 
positions. These could also be programmed to send keystrokes and they 
acted like the buttons.

Now for my opinion:

This seems to be an implementation detail and I think it is ok if the 
effect of buttons goes only to the app with the pointer focus.

The default setups make the buttons act like all the different modifiers 
so you can do shift+click on the pad. On OS/X one of the buttons is set 
so when held down it causes the pen to send x/y mouse scrolling events. 
The small vertical strips are set in both cases to "smart scroll" which 
it is unclear what it does, and imho setting them to the scroll wheel 
works better ("smart scroll" may be an attempt to work around Window's 
very broken policy of sending the scroll wheel to the keyboard focus). I 
think this covers what is needed for "tablet unaware" applications. I 
suspect that the modifiers only have to work at the moment a click is 
sent from the pen, though working the way Windows and OS/X does might be 
the easiest implementation but users are not relying on it.

The reason for the keystrokes is obviously to trigger shortcuts in the 
application the pen is being used on, such as to switch tools in 
Photoshop. I suspect it would be ok if they went to the client with 
pointer focus (it could ignore them if it does not have keyboard focus 
if that helps). They can also be unique buttons, it would be much better 
if the client provided the api to change what the buttons do.