multi-touch-dev team mailing list archive

["Henrik Rydberg" <rydberg@xxxxxxxxxxx>]

> > 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've been trying to come up with a scenario that demonstrates how this
> approach would be cumbersome and difficult. The problem is that every
> scenario I come up with can be "special cased" somehow. But I believe
> that each special case will end up with it's own issues.
> 
> As an example, lets say you special case two finger drag as scroll as
> you describe. You have an application that wants multitouch events. It
> also wants to be able to scroll. The use case desired is that an
> initiated two finger drag (you must go from 0 to 2 fingers dragging
> within a small time interval) scrolls an object.

The desired usecase is that at any moment there are two fingers on the
pad, scrolling is performed. No timeouts or anything like that.

> However, other touch
> motions like going from one finger to two to three are to be interpreted
> differently.

One to two should be the same as zero to two in this case, i.e., there
should be no account of history. Moving to three is not part of this
particular usecase.

> Perhaps it's a multitouch drawing application. If you
> assume that any two finger drag is always a scroll, then it may become
> impossible to interact with this application with two fingers. However,
> the application would work as desired when using the utouch stack as
> I've got in the ppa. To be clear, although this may seem a contrived
> example, I believe we must cater to applications that want full MT
> capabilities with any specific number of simultaneous touches while
> still being able to handle obvious and deliberate gesture input.

The example is much simpler than this - an application that does not
care about MT events but just wants scrolling to work as before.

> Essentially, there will always be holes one can poke in MT and gestures.
> I feel we should aim to be as simple as possible, while being mindful of
> any glaringly bad side effects. I don't see inhibiting position then
> scroll then position as a terrible side effect that is worth special
> casing and making other things potentially more difficult.

Please consider the possibility that it _is_ a glaringly bad side
effect.

We are talking about the special case of a trackpad moving the input
focus with a finger. If we were to consider this the same as hovering,
for example, we would automatically draw these conclusions:

1. It is not a touch, it is merely moving the input focus.

2. Since it is not a touch, it is not an MT touch either.

In the hovering context, adding an additional N fingers would mean N +
1 touches appear at the same time, which is what has been suggested as
a solution. There is most likely no need to be as drastic as not
presenting the first finger as a touch, but the notion should be
clear.

As a general remedy, using a sort of enter/leave notion for touches
was suggested during the development of the XI2.1 spec. What was the
major objection to that idea?

Thanks,
Henrik