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. > >> 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. > > The point is that this is only one use case. We have to cater for all > (or most) use cases simultaneously. It is enough with one example to falsify the current model, why complicate it further? > I also disagree that this use case is universal. I believe there are > times where you have a scrollable object, but you want to be able to > perform a multitouch operation or other gesture on it. Say you've got a > canvas in gimp and you want to be able to rotate it at 90 degree > intervals as well as scroll it. You don't want to allow rotation and > scrolling simultaneously. So, you have to lock on to one or the other. > If you always assume scrolling, you'll never be able to rotate. > > >> 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. > > But it may be a use case for a different application. We should not > break one use case to insert another without fully weighing the impact > of both. Again, it is enough to consider this one usecase to point at the problems with the current implementation. Adding additional cases will not make it more correct; it will rather make it worse. > >> 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. > > This is an argument considering only the one scrolling use case again. > We can't be single minded about use cases. I keep repeating this single usecase because it does not seem to sink in. > >> 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. > > I will. In fact, I would be interested to hear how many people use their > trackpads like this today, how many don't, and how many never even > thought of it before. As you pointed out elsewhere in the thread, this > isn't supported only by OS X, but also by synaptics in X. However, I > personally have never used a trackpad in this way, nor have I even > thought about it (which is probably clear by now :). The same is the > case for my wife, who happens to be sitting next to me. I honestly find that hard to believe. In contrast, having worked on trackpad gesture intricacies for quite some time, I find this usecase frequent indeed. > So, I'd be interested in hearing how others use their trackpads in this > regard. Maybe I'm wrong, and we do need to rethink this. Or maybe the > usage is more like the usage of fluxbox: there are those who really want > it, but almost nobody uses it when looking at it statistically. Give me _one_ good reason why we should resort to a numbers game because the real world does not fit the current technology. > > 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. > > Are you suggesting that we don't post touch events from a trackpad until > at least two touches are active? If so, an application would need to > watch cursor motion and convert it to touch motion internally if another > touch point begins. That does not seem like a good interface to me. As I wrote above, that should not be necessary. Just think about it on a conceptual level. > In your last sentence you seem to imply there may be a way around this > without presenting the first touch as only cursor motion. I don't > believe there's a reasonable way to do this, so I challenge you to come > up with a method :). There are intricacies with where pointer events are > sent vs where touch events are sent that make everything in this area > difficult. To move forward, we need complete ideas that address how > events are generated and delivered for cursor motion and touch events, > including where events are sent when the cursor moves from one window to > another. I do not have to resolve the problem in order for the problem to exist. > > 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? > > I don't remember this. Can you refresh my memory? Let's save that for another thread. 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
