The idea is to simplify the way the output module currently works by:
- introducing an abstraction that represents blocks; these abstractions
contain all data - uninterpreted - required to draw a block
- separately from that, whenever the block is serialized into JSON,
do the interpretation (pango vs. non-pango, etc.)
This - theoretically - should simplify code by creating two separate
concerns: collecting the data and actually interpreting it.
Allow any piece of a theme that specifies a set of attributes (default,
cycles, states, widgets) to use pango *instead* of the usual attributes.
If pango is present, this will have precedence.
A practical example of this can be found in the powerline-pango theme,
which is added solely for demonstration purposes.
fixes#531
When rotating theme values (e.g. the "charge" icon of the battery
module(s)), until now, the code just showed the raw list (because it
wasn't aware of the need to rotate).
Implement a generic "load keywords and replace during runtime"
mechanism, with the first concrete use-case of WAL colors (load them
during startup, and during runtime, whenever a matching name is found in
the keywords, replace with the actual color)
Add states to the modules and widgets. Widgets are mostly just a
pass-through (backwards compatibility, and ease of use - making states
directly inside the widgets would require more code inside the modules
to ensure that each widget is correctly updated).
Still missing:
- Separators during partial update (right now, it takes one interval
until separators are drawn correctly)
Add a way for themes to specify custom separators. Doing that, make
nicer interfaces for drawing "supplementary" components (separators)
for widgets and generalize the attribute retrieval within the theme.
Add two new parameters: theme and iconset
Add a placeholder class core.theme.Theme, an instance of which is passed
in to the i3 output object (which is the only object that should ever
have need of the theme, hopefully).
