| |||||||||||||
Excellent article, and a sugestionExcellent article, and a sugestionPosted Mar 8, 2012 7:56 UTC (Thu) by michaeljt (subscriber, #39183)In reply to: Excellent article, and a sugestion by mhelsley Parent article: The life story of the XInput multitouch extension
mhelsley wrote:
> "A solution for such cases would be to define "private" touch zones. Any touch initiated in such zones would be handled exclusively by that application."
> Sounds fine for a touchscreen but it doesn't make as much sense on a touchpad where even a small "private" zone would be a poor use of the small area.
I realise that this train has left, but what is the reason for handling touch screens and touch pads the same? I would naively assume that all touch pad gestures would automatically go to the currently focussed window.
(Log in to post comments)
Excellent article, and a sugestion Posted Mar 8, 2012 10:25 UTC (Thu) by daniels (subscriber, #16193) [Link]
Yes, this is exactly what the X multitouch support does.
Excellent article, and a sugestion Posted Jun 7, 2012 10:58 UTC (Thu) by cheako (guest, #81350) [Link]
I think there is a misunderstanding here. I believe that michaeljt is indicating that _only touch pad_ gestures would automatically go to the currently focused window. While it's clear to me that with a touch screen one can interface with any window the user touches.
Thus we are convinced that touch screens and touch pads will have diverging code paths and it would be possible to implement a fix or feature in one with out effecting the other at all.
Thus the solution is to have private zones for a touch screen and use the existing key board locking for a touch pad.
|
|||||||||||||