Re: Multitouch review 2: press-and-hold

Hey :),

On vie, 2012-02-03 at 03:36 +1000, Peter Hutterer wrote:
> >> Questions, comments:
> >> 
> >> - This is almost convenience api - except for the interaction with
> >> event capture, every widget could do this itself with a timeout and a
> >> handrolled animation. But having this supported consistently across
> >> the desktop seems well worth it. The branch add press-and-hold support
> >> for the context menus in entries, labels and textviews.
> >> 
> >> - I wonder what happens on a multi-touch system - if I touch and hold
> >> 2 buttons, do I get two press-and-hold animations at the same time,
> >> with 2 context menus popping up in the end ?
> >
> > Hm, right, I meant to have it work only for the touch sequence that
> > emulates pointer events, but forgot to do this change.
> I do wonder though what a "right click" would be for a pure touch events and
> how there can be consistency on such touch-and-hold events. Would this add
> too much pointer semantics to a touch event?

That's a fair point, there's not much in the press-and-hold
implementation that ties it to a single touch, although the most common
reaction to it would be emulating right click behavior, but the menus
typically popped up on these do grab the device, and request exclusive
attention, thus the intent to limit it to the touch emulating pointer
events. I'm not aware either of any common interaction pattern that
could benefit from multi-press-and-hold

Also, most widgets that might want press-and-hold won't listen by
default to touch events, so they'll just receive events from the
emulating touch anyway.


> Cheers,
>   Peter
> _______________________________________________
> gtk-devel-list mailing list
> gtk-devel-list gnome org

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]