Re: touch events

On jue, 2012-02-02 at 21:01 +0100, Benjamin Otte wrote:
> So from reading Matthias' mails it seems to me that this is the first
> step, so we should get this right first. We should have a good idea of
> where we want to go, but we don't need to merge the full multitouch
> branch to get touch events. So let's start small.
> Note that I do not have any touch-capable devices, so I have no way to
> test the things I'm suggesting here. All I can and will do for now is
> API review.
> For now I'll only care about event delivery of touch events and ignore
> crossing events, pointer emulation and those. I do however care about
> portability to Windows and OS X. (I'll ignore Wayland because I assume
> it'll be similar/identical to X11).
> As a guidance, I've looked at the following documents:
> - X11
> - Windows
> - OS X
> - Qt (for reference)
> As far as I understand, none of these are concerned with multitouch;
> multitouch is something that is implemented on top of this basic
> system by the machinery commonly known as "gestures".
> In all of these, touch is implemented via touch "sequences". A
> sequence is a list of events, always delivered like this:
> 1 BEGIN event
> 0 or more UPDATE events
> 1 END or CANCEL event
> Each of those events carries a designated ID that identifies the sequence.
> There are some differences however, and I'm not sure if we need to
> care about those right now or if we can think about them later:
> - CANCEL vs END may be a flag on a single END event (X11) or two
> separate events (OS X). (I personally prefer the OS X part, because
> cancelling vs performing an action is a very different thing).

CANCEL in osx seems to be most similar to ::grab-broken-event, not sure
what would buy us having 1 event per touch instead of per device. 

On X11, If you refer about XITouchPendingEnd, you can only possibly get
that if you set XI_TouchOwnership in the evmask, this is a mechanism to
allow early, but cancel-prone, processing across the WM and other
services handling the same touch events simultaneously. Regular clients
have more pain than gain in handling unowned events.

> - Some operations on X11 require "accepting" a touch sequence (in
> particular for grabs).

Again part of touch ownership, unrelated to what you think it is.

> - Some update events distinguish between "did move" and "did not move"
> (OS X, Qt).
> The current multitouch patchset implements touch events by using
> GdkButtonEvent and GdkMotionEvent and appending a sequence id to them.
> Apart from the fact that I'm not sure if that's API stable (my guess
> would be "hell no"), I don't like that approach. The platforms above
> seem to agree with me. Qt, Windows and OS X have a custom TouchEvent
> for that purpose.
> I did not look at all yet at what contents a GdkTouchEvent should have
> and how references to previous events should be handled. My gut
> feeling says "let the sequence take care of it", Qt says "we'll give
> you a list of all motion points and lots of other points, too", I
> didn't look at other toolkits.
> I would also prefer the touch sequence to not be hardcoded as an
> integer, but encapsulated - a pointer typedef for example. This would
> allow adding features to touch sequences later on (like the accepting
> stuff from X11 grabs).

Touch grabs, and accepting/rejecting sequences has little to do in GTK+,
unless the usecase is mutter.


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]