Re: Multitouch review 1: event capture

[Matthias Clasen <matthias clasen gmail com>]

On Tue, Jan 31, 2012 at 2:59 PM, Benjamin Otte <otte gnome org> wrote:
> Matthias Clasen <matthias.clasen <at> gmail.com> writes:

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

Expose isn't. Neither is delete. The dnd events are special too. But
everything else goes through capture.

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

It has to be public api if you want to support 3rd party widgets with
similar capabilities. And I think we do want to support that.

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

Nothing has changed here. GTK+ determines the target widget the same
way it has always done. We will have to change that in a window-free
world, maybe. But figuring out the answer to that question does not
block the capture work, as far as I can see.

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

If you want to handle an event on the way down in the capture phase,
you have to handle it in the ::captured-event handler - ::event
handlers are not run during this phase at all. And yes, the dom api
for this looks slightly different, where event listeners are marked as
being 'capture' or not.

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

Its only a problem if you view everything through the w3c lense. We
are not implementing the dom spec here, we are retrofitting the
capture phase into the existing GTK+ event handling framework. A
highlevel description of the clutter event propagation is here:
http://docs.clutter-project.org/docs/clutter/1.8/ClutterActor.html#ClutterActor-event-handling

>>  - 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 code as currently written does not attempt to handle vanishing
targets. It calls gtk_get_event_widget - which will return NULL in
that case, so it would be straightforward to just drop the events.

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

No, what is implemented here is exactly what you need to prevent that
- if there is a grab inside the scrolled window, it does not get to
capture the events away, since the capture phase is only done from the
grab widget downward.