On 03/02/2011 06:29 AM, 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. > >> 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? > >>> + 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.
Everything stated here sounds good to me too. -- Chase _______________________________________________ [email protected]: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
