[docs] capy in a GUI application

[LegalizeAdulthood]

(Moved from corosio)

Capturing this from a discussion with @vinniefalco on slack.

Can we treat a GUI application's event loop as just another source of events in a coroutine based application?

How does capy integrate with the event loop in a GUI application?

Obviously you can just run all capy stuff on a separate thread and use traditional event posting mechanisms to communicate between a worker thread and the GUI thread, but what if you just want to do everything event-driven on a single thread?

Some sort of example would help here.

It may be an example in a distinct repository to decouple capy's repository from any GUI library, e.g. an example using wxWidgets and vcpkg.

[vinniefalco]

I have no idea. Typically GUI frameworks call member functions with events when they occur (JUCE, Win32, QT for example). It is not clear to me how the coroutines help, as coroutines solve a different problem: how to handle the case where you have to wait in the middle of a function. GUIs don't work that way. The user performs an action, and it is handled synchronously.

[LegalizeAdulthood]

At the bottom of the stack is a message loop that asks: is an event available? if so, send to handler.

For most applications, they use the stock event loop implementation from their framework.

However, lots of GUI apps do "cooperative multi-tasking" whereby they ask the event loop if there are any messages pending and if not, they do background tasks.

This is starting to sound like coroutines being activated when I/O is available, isn't it?

[LegalizeAdulthood]

There are also similar background scenarios that occur in console applications, e.g. a news reader

[vinniefalco]

Reading and writing the console is an I/O operation and this is in scope