← Back to team overview

multi-touch-dev team mailing list archive

Re: A new release of xi 2.1 + utouch stack in xorg-unstable ppa

 


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?

Thanks,

d




Follow ups

References