Previously, the 'content' of i3 was a map, where the keys where i3
workspace names, mapping to a particle template.
Now, that configuration type is still allowed. But we also allow a
variant where the 'content' is a list, of either 1 or 2 entries.
Both entries *must* be dictionaries. The key is either 'dynlist',
which is the same as the dictionary-only type of
configuration. I.e. it maps to a dictionary where the keys are
workspace names, mapping to particle templates.
If the key is *not* dynlist, then it is assumed to be a particle name,
and we treat that as a "regular" label, that will be appended after
the workspace dynlist when instantiating the content.
This particle will be instantiated with, for now, the title and
application of the _currently focused_ workspace.
This is done on a per-workspace basis.
Note that the initial state is currently not detected. I.e. we
retrieve the initial workspace list, but we don't get the currently
focused window.
In cases where it makes sense, use calloc() instead of malloc():
* When allocating large objects with many members, many for which
NULL/0 is a good default value.
* Arrays etc where we explicitly initialize to NULL anyway.
This fixes an issue where switching between empty workspaces (or one
empty, one non-empty) momentarily flashed two workspaces.
I.e. we immediately rendered the new workspace, and then re-rendered
when the first workspace was destroyed.
There's no pkg-config file shipped with i3, so our only option is to
manually look for the file (and assume it can be found in the "normal"
include paths).
De-registering events from the previous active window may fail (when
the previous window has been destroyed).
Catch this early, and only log a debug message. This avoids having a
normal occurrence polluting the output with error messages.
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.
