multi-touch-dev team mailing list archive

[Chase Douglas <chase.douglas@xxxxxxxxxxxxx>]

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