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
_______________________________________________
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
