ryanisaacg / blinds Goto Github PK

Moving this topic from ryanisaacg/quicksilver#552

Its seems pretty straightforward to make an async call (like, by using platter.load_file), await that call (blocking the application loop) and resume the program execution upon the completion of the call. This will work for situations like loading game initialization data, and may be acceptable in some situations like switching "levels".

However, what's not clear is how to setup custom non-blocking events. Something that feels like

• Initialize my own custom event stream with a custom type
• Setup async tasks, registered to the custom event stream which, upon completion, enqueues the task output as a custom event
• During each "big loop"
  • Poll the blinds EventStream for window events until exhausted
  • Poll the custom event stream for custom events until exhausted
  • Run my main logic
    • Drawing
    • Triggering more async tasks, similarly registered to the custom event stream

I think that this would cover things like sockets/websockets (I have a long-lived connection to the server) as well as remote procedure calls and non-blocking resource loading.

The API should ideally allow end-user to specify which parent node the canvas should be attached to.

There's some stuff in https://www.falseidolfactory.com/2020/04/01/intro-to-gfx-hal-part-1-drawing-a-triangle.html that uses winit that I can't find a blinds equivalent for. Mostly the Logical/Physical split, requesting to close a window (i.e. if cleanup needs to be done before hand, or a confirmation box should be displayed), and the "request redraw" events.

Is there an example of using blinds with gfx-hal?

It may be possible for blinds to support multithreading on desktop execution, which would allow background execution of tasks. This may make integrating with the winit event loop more complicated, though.

With removing the gamepad cache layer, the gamepad metadata is no longer available.

Technically adding an event is a breaking change, as is adding any information to the events themselves. Event variants that contain opaque structs should be more resilient and allow non-breaking changes.

This also enables marking key events as repeats

The eventstream only awakes when there are new events to process, so even though the event loop is set to poll it behaves like Winit's Wait.

Some errors mostly can't be addressed by the user, but are also not fatal. The API should somehow reflect this.