On Wed, Mar 02, 2011 at 11:29:22AM +0000, Daniel Stone wrote: > Hi, > > On Wed, Mar 02, 2011 at 04:34:30PM +1000, Peter Hutterer wrote: > > On Tue, Feb 08, 2011 at 10:53:19AM +0000, Daniel Stone wrote: > > > --- a/XI2.h > > > +++ b/XI2.h > > > @@ -67,6 +67,7 @@ > > > #define XIGrabtypeEnter 2 > > > #define XIGrabtypeFocusIn 3 > > > #define XIGrabtypeTouchBegin 4 > > > +#define XIGrabtypeTouchBeginInert 5 > > > > I'm struggling to come up with a better name but I'm not sure Inert is the > > best option here. > > I thought of a better name on the way to the train, and then forgot it. > Ugh. > > Oh! 'Observer'? > > > > @@ -83,8 +84,8 @@ > > > > > > /* XIAllowTouchEvents bitmask event-modes */ > > > #define XITouchOwnerAccept (1 << 0) > > > -#define XITouchOwnerReject (1 << 1) > > > -#define XITouchNoPointerEmulation (1 << 2) > > > +#define XITouchOwnerRejectEnd (1 << 1) > > > +#define XITouchOwnerRejectContinue (1 << 2) > > > > just thinking aloud: XITouchOwnerReject and XITouchOwnerPass? > > or XITouchOwnerIgnore and XITouchOwnerPass? > > > > also, after 10 minutes of reading this over and over I found what was > > bothering me. We have XIGrabtypeTouchBeginInert for the grab type to get the > > behaviour that XITouchOwnerRejectContinue gives us too. these two need to be > > consistently named. to go with my suggestions from above: > > XIGrabtypeTouchBeginPass and XITouchOwnerPass? > > How about TouchBeginObserve and TouchOwnerObserve? I'm sure we could do > better, but it's a start.
I had to read this thrice to see the difference between Touch>>Begin<<Observe and Touch>>Owner<<Observe. This is bound to be a source of bugs. However, I am partial towards TouchReject and TouchObserve. Observe is definitely a good name for this approach. which brings me to the next thing - s/Owner// in the defines above? > > Chase, this should also clarify your comment here. Inert isn't a new event > > type it's a grab on touch with an automatic RejectContinue if the grab > > activates. > > Yep, just avoids a round trip. > > > > + TouchAccepted (for TouchEnd events only) means that the current > > > owner > > > + of the touch stream has “accepted” it, and this client will not > > > receive > > > + any further events from that touch sequence. > > > > > > thinking about this again, it leaves us with a strange situation for > > RejectContinue: > > Given the window hierarchy A being parent of B being parent of C and touch > > grabs by different clients on all three. > > > > Touch starts > > * TouchBegin + TouchUpdate to A > > * TouchBegin + TouchUpdateUnowned to B and C > > > > RejectContinue on A > > * TouchUpdateUnowned to A > > * TouchOwner + TouchUpdate to B > > * TouchUpdateUnownd to C > > > > Accept on B > > * * TouchUpdateUnowned to A, or > > * TouchUpate(End) to A > > * TouchUpdate + eventual TouchEnd to B > > * TouchUpdate(End) to C > > > > > > so depending on what we do with A, we have the two different scenarios: > > - if we keep sending events to A, this means that you can only do touch > > event monitoring (such as for the visual feedback) you're on top of all > > other windows. all clients will thus race to the top and compete there > > (only one client can select on a window, right?) > > - if we stop sending events to A, then exactly the features this would allow > > aren't possible (and GrabtypeInert/RejectContinue becomes rather > > pointless) > > > > The only solution seems to be keep sending UpdateUnowned events regardless > > of the "accept" status. this needs to be worked into the text. > > Oh, ugh. I think we should do the observer rename, and state that > observer grabs, or grabs where ownership has been passed on with > TouchOwnerObserve, will always receive all events between the first > TouchBegin sent to any client, and the last TouchEnd. > > Does that sound OK? yes, that makes sense. Cheers, Peter > > > + other grabs (including device freezing), although any pointer events > > > + generated by emulation will still be subject to all the same > > > constraints > > > + as normal pointer events, including enter/leave events, and being > > > affected > > > + by frozen devices. > > > > btw, what will get really interesting is if you have a confine_to window > > involved. I think the best solution here is to simply state that confine_to > > only > > affects pointer emulation but not touch events. > > Yeah, I'll be more explicit about that. > > > I think this looks good, but by now my head is rather spinning. > > Thanks, I'll sort all those out for the next revision I send out. > > Cheers, > Daniel _______________________________________________ [email protected]: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
