On 02/07/2011 02:28 PM, Duncan M. McGreggor wrote: > On Feb 7, 2011, at 9:58 AM, Henrik Rydberg wrote:> >> On Mon, Feb 07, 2011 at 12:16:20PM -0500, Chase Douglas wrote: >>> On 02/07/2011 11:00 AM, Henrik Rydberg wrote: >>>>>> This is a function of the fact that you can do two very >>>>>> different things >>>>>> with your finger: move the pointer, or interact with content/ >>>>>> gesture. I >>>>>> think we could special case that in pointer-based environments >>>>>> like the >>>>>> desktop, so that single-finger pointer moving actions come to an >>>>>> end >>>>>> when additional fingers are brought to bear, at which point a >>>>>> gesture is >>>>>> begun. Would that address the issue? >>>>> >>>>> The devil is in the details here. The worry is that we can find >>>>> ourselves in inconsistent states and/or complicate the >>>>> implementation to >>>>> the point that it's unworkable or prohibits other use cases. >>>> >>>> I don't think we need to over-dramatize this particular case. >>>> Rather, >>>> acknowledging that a hovering pen, a finger on a trackpad, and a >>>> hovering finger on a screen all constitute a real situation not >>>> properly accounted for, should make it possible to resolve this >>>> issue >>>> cleanly. >>> >>> I agree that xi 2.1 doesn't handle this cleanly. The major reason for >>> this is the interaction between touch and cursors, and gestures and >>> X. >>> We are trying to fit touch into a system that is poorly designed >>> for it, >>> and we are trying to fit gestures either before the X input stack or >>> after it. No implementation is going to be perfect given these >>> constraints. >>> >>> We can strive for a better system in wayland, but some compromises >>> must >>> be made for X. >> >> Again, I think we need to turn the logic upside down. What do we need >> to achieve what we want, and do it that way. > > Hey guys, I need to jump in here. > > We have a very, very limited amount of time to accomplish two > significant things: > 1) get XI2.1 ready and working with GEIS > 2) get grail2 working with new additions to GEIS > > We're so tight on time right now that if there is a regression and it > gets us 90% there, that's better than spending too much time on a > refactor or implementing a new solution a loosing a week's worth of > work. It saddens me to say it, but we are very thoroughly into the > "heavy compromise" part of the timeline. > > That being said, if there are many regressions, something's wrong and > we need to address it. If these exist, they need to be identified and > changes need to be made. If there's no evidence for additional > regressions, let's move on and get some work done; this is software, > there will always be bugs, no matter what we do. > > Here's what I need from you guys: > > What technical solution will get us to beta freeze the quickest, with > the least amount of fundamental changes to the current architecture, > with the most amount of currently-existing code in place?
I see grail 2 as an attempt to put grail on the client side of X (thus using xi 2.1) and adding in combinatorial gestures for the possibility of multiple simultaneous gestures within the same X window. If the latter isn't implemented, rebasing on top of xi 2.1 is still a step forward. The issue here is how we handle the interaction between grail for gestures and X for multitouch and pointer emulation. In my head, I think the easiest thing is to do what I've done with grail 1 in the xorg-unstable ppa: add timeouts to pass events through to X for multitouch and pointer emulation. Unfortunately, I can't think of a simple rework that can be accomplished in two and half weeks and gets us any closer. Thanks, -- Chase _______________________________________________ Mailing list: https://launchpad.net/~multi-touch-dev Post to : multi-touch-dev@lists.launchpad.net Unsubscribe : https://launchpad.net/~multi-touch-dev More help : https://help.launchpad.net/ListHelp
