POC: event handling using await #98
Draft
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This is a proof of concept for an idea to allow users to handle events using await. An event handling workflow can then be written as a single async function, which can be much easier than listening to multiple events and maintaining state across the handlers.
Example implementing drag:
The use-case that triggered me to think about this more is the lasso tool in FPL: fastplotlib/fastplotlib#837
I'm curious to what @Korijn thinks of this idea from a design/API perspective, and what users like @kushalkolar, @hmaarrfk, @claydugo, @kingbedjed think of writing handlers this way. I think it should be an alternative to
add_event_handler
, not replace it.Some notes regarding async:
await sleep()
, but you shouldfrom rendercanvas.asyncs import sleep
to make it portable.Some caveats:
try except
.Some ideas:
for_event()
instead of the emitted object (see example above).canvas.add_event_task("pointer_down", func)
so the task is initiated for every mouse down, avoiding onewhile loop
.