Instead, we need to check if xcb_connection_has_error() says something
went wrong. We also need to call xcb_disconnect() on the disfunctional
XCB connection object.
By default, generates an error message with the major/minor opcodes,
the error code and sequence number.
If available, it will use xcb-errors to generate an even better
description.
All modules are expected to handle a call to content() after having
been instantiated.
I.e. modules *cannot* even expect run() to have started running.
This fixes lots of memory leaks detected by valgrind.
Unsure if this is how you're supposed to shutdown cairo. You'd
think (from the documentation) that destroying the surface would (when
the refcount reaches 0) destroy the device too...
Before shutting down and destroying cairo and XCB, make sure the
modules, particles and fonts have been destroyed.
I.e. move module destruction from bar's destroy() to the end of bar's
run()
For this to be doable, the bar no longer destroys the module's
exposables after rendering them. Instead, we keep them around, letting
them represent the "current" content of the bar.
Then, when we receive a mouse motion event, we can iterate the
exposables and calculate which one of them the mouse is over, and call
its on_mouse() function.
This also means that modules do *not* have to call bar->refresh() just
before/after calling module_signal_ready().
As long as the module's initial state has been correctly/completely
set up before it calls module_signal_ready(), the module *only* has to
call bar->refresh() when it's state changes.
After starting all the module threads, wait for all modules to have
signalled "ready" before continuing.
This will allow modules to do initial setup, and knowing that
content() will *not* be called until they've signalled "ready".
