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.
_______________________________________________
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
