These functions don't exit immediately, but rather on the next iteration
of the event loop.
Since exit() is already used by the standard library, let's call it quit()
instead. That way, saying exit() means the same thing here as anywhere else.
To facilitate listening for action on arbitrary file descriptors,
I've added a GNotifier class. It's quite simple but very useful:
GNotifier notifier(fd, GNotifier::Read);
notifier.on_ready_to_read = [this] (GNotifier& fd) {
// read from fd or whatever else you like :^)
};
The callback will get invoked by GEventLoop when select() says we
have something to read on the fd.
Clicking the button generates a WindowCloseRequest event which the client app
then has to deal with. The default behavior for GWindow is to close() itself.
I also added a flag, GWindow::should_exit_event_loop_on_close() which does
what it sounds like it does.
This patch exposed some bugs in GWindow and GWidget teardown.
Instead of clients painting whenever they feel like it, we now ask that they
paint in response to a paint message.
After finishing painting, clients notify the WindowServer about the rect(s)
they painted into and then flush eventually happens, etc.
This stuff leaves us with a lot of badly named things. Need to fix that.
To start painting, call:
gui$get_window_backing_store()
Then finish up with:
gui$release_window_backing_store()
Process will retain the underlying GraphicsBitmap behind the scenes.
This fixes racing between the WindowServer and GUI clients.
This patch also adds a WSWindowLocker that is exactly what it sounds like.
There is some trouble here with the asynchronous nature of WindowServer
and the single per-window backing store we're drawing into. If we start
repainting a widget with a pending invalidation, that invalidation might
get flushed by the WindowServer mid-paint.
