Re: Multitouch review 1: event capture

[Benjamin Otte <otte gnome org>]

Matthias Clasen <matthias.clasen <at> gmail.com> writes:
> 

General questions:

- How does that integrate with EventControllers?
This is more of a "thing to think about" than a question, but I think it's
interesting that this works well in a world where we have EventController
objects and run on top of Clutter. So I guess that's a question for Emmanuele?

- the name "captured-event"
I think the name "capture-event" is better, I'd probably just use "capture" as
event handling is a very generic operation on the widget.

- If we change things, how far can we go?
We know we want to end up mirroring Clutter and the web. If we introduce new
events, can we do that in a way that stays compatible with the old way of doing
things but brings us as close as possible to the new world? Is this approach as
good as it gets or can we do better?


Going into detail on your mail:

> API:
>   GtkWidget::captured-event signal
>   GTK_CAPTURED_EVENT_{HANDLED,STORE}
>   gtk_widget_release_captured_events
> 
- What events are running through the capture phase?
I suppose everything from keyboard over press/release to focus-in/out is
captured? But Expose certainly isn't.

- Is "store" something that should be exposed in the general API?
It seems to me that it's something that the widget should do, not something we
should expose in general-purpose API. Or to be more blunt: I think this is
ScrolledWindow only code and should never reach public API.

- How does this interact with no-window widgets?
Or asked differently: How do we determine which widget is the target? In the
GTK2 world, the target was always the widget owning the GDK window the event was
delivered to. Should we keep that? (This question is both relevant to existing
events and to the new touch events)

- Are you supposed to handle the event in the capture event?
Or is the event just a yes/no question and handling should be done in the actual
event handlers?
Because I think the web and the description you posted disagree here. I'm also
not sure about Clutter at all.

> This API looks reasonably straightforward to me, and matches well with
> the web model[1].
>
The web defines 3 phases: capture, target and bubble, see
http://www.w3.org/TR/DOM-Level-3-Events/images/eventflow.svg for a nice graphic.
I'm not sure this is represented well in this API, in particular there is no
difference between target and bubble. I'm not sure how much of a problem this
is, but wanted to point it out. Also: Clutter.
And of course: The aforementioned EventController integration.

>  - When captured events are released, they are not further propagated
> via ::captured-event, but directly to the target widget via ::event.
> Is that good enough ? It does not allow events to be captured multiple
> times, but maybe that is an unlikely enough scenario that it does not
> matter...
>
How does that work if the target moved or was destroyed while the events were
stored? Do we drop the events? It seems to me that instead of storing we should
synthesize new events instead. I wonder how overlaying event handlers works on
the web?
 
> - The docs for ::captured-event should explain the interaction with
> grabs - in the presence of a grab, the ::captured-event signal is
> emitted starting at the grab widget, not the toplevel.
> 
Did anybody think about this some more? Because grabbing inside a ScrolledWindow
might get funny effects that you wouldn't expect when you grabbed stuff because
the ScrolledWindow captures your events away from you?

Benjamin