Re: Multitouch review 1: event capture

[Carlos Garnacho <carlosg gnome org>]

Hey,

On mar, 2012-01-31 at 11:09 -0500, Matthias Clasen wrote:
> API:
>   GtkWidget::captured-event signal
>   GTK_CAPTURED_EVENT_{HANDLED,STORE}
>   gtk_widget_release_captured_events
> 
> General idea: The ::captured-event signal is emitted top-down,
> starting at the toplevel (somewhat different in the presence of grabs)
> all the way down to the widget that received the event. If the
> propagation is not interrupted (see below), the next phase is to emit
> the traditional ::event signal, starting from the innermost widget,
> and then upwards. The per-event signals (like ::button-press-event)
> and the ::event-after signal are also delivered as they always have.
> 
> toplevel -> ::captured-event
>   container1 -> ::captured-event
>     container2 -> ::captured-event
>        button -> ::captured-event
>        button -> ::event
>     container2 -> ::event
>   ...
> 
> Each intermediate ::captured-event handler can declare the event
> handled by returning GTK_CAPTURED_EVENT_HANDLED. This stops the
> further propagation of the event. Optionally, the handler can request
> that the event be store for later replay, with
> GTK_CAPTURED_EVENT_STORE. gtk_widget_release_captured_events() can
> later be called to release or drop the stored the events. The use case
> for store/release is that e.g. GtkScrolledWindow can capture events
> that might lead to scrolling, and when it turns out that it was just a
> press/release without motion, it
> can pass the stored events on to the child widget.
> 
> This API looks reasonably straightforward to me, and matches well with
> the web model[1]. Questions, comments:
> 
>  - 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...

I was a bit wary here about events being held indefinitely, or arriving
at a time when they wouldn't make much sense anymore if it's kept too
long along the hierarchy. But those would generally be bugs in widgets,
and it is also necessary to keep events paired on ::captured-event, so
probably worth changing. Things could also benefit when other container
widgets get to handle ::captured-event.

> 
>  - The docs warn about the fact that storing events takes no
> precaution about pairedness of enter/leave, etc. There is certainly
> some danger that careless picking of events could seriously confuse
> the widget 'downstream'. Is there a use case for storing individual
> events while letting other pass through ? If not, we could consider an

There are cases where you might want to let button-release go through,
but calling gtk_widget_release_captured_events() before in order to
release the pairing button press that was stored, the
no-motion-really-happened scrolledwindow case is one of those.

> alternative where you can turn storage of events on/off, but not for
> individual events. Would that be better ? Maybe not...

I thought about alternatives, but being there multiple event types that
need to be paired, and as widgets may want to capture several of those,
couldn't think of anything better...

> 
>  - The 'release' in gtk_widget_release_captured_events clashes a bit
> with the 'release' we have in a bunch of event names:
> button-release-event, key-release-event... Probably not a big deal.
> And 'replay' does not have quite the right meaning.
> 
> - 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.

Right

> 
> 
> [1] http://www.w3.org/TR/DOM-Level-2-Events/events.html#Events-flow-basic
> _______________________________________________
> gtk-devel-list mailing list
> gtk-devel-list gnome org
> http://mail.gnome.org/mailman/listinfo/gtk-devel-list