> > 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?
Simply reverting a recent change might do the trick. > 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. With server-side grail, there is no technical reason why gestures cannot be emitted in-flight, i.e., even though a touch is presented to the application. Let's solve this on IRC and leave the poor folks in peace. Henrik _______________________________________________ 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
