> * reject needs to remove all matching gesture events from the geis queue.
>
> Since it's impossible to guarantee at the API level that no further event for
> a rejected gesture will ever come through (event generation is asynchronous
> over possibly several processes), I figured the application needs to handle
> this anyway. However, since it is not a big effort to remove these events
> from the internal GEIS queues, I added this and extended the test case
> accordingly.
Grail does guarantee this. It does the same queued event removal that you implemented for geis. This ensures that no further events may propagate up the stack after a rejection.
If we implemented things right, the application should not receive any events after a reject call.
Everything looks good to me now. Let's get this merged and released!
> * reject needs to remove all matching gesture events from the geis queue.
>
> Since it's impossible to guarantee at the API level that no further event for
> a rejected gesture will ever come through (event generation is asynchronous
> over possibly several processes), I figured the application needs to handle
> this anyway. However, since it is not a big effort to remove these events
> from the internal GEIS queues, I added this and extended the test case
> accordingly.
Grail does guarantee this. It does the same queued event removal that you implemented for geis. This ensures that no further events may propagate up the stack after a rejection.
If we implemented things right, the application should not receive any events after a reject call.
Everything looks good to me now. Let's get this merged and released!