With this commit, it is possible to add pango directives inside every
piece that supports direct output (e.g. defaults/prefix or <module
name>/prefix) and those will be merged - i.e. it is possible to specify
defaults inside "defaults" and override/specify in the particular
modules.
According to the unit tests, at least, the old functionality is back
again - with the additional i3 block abstraction in output in place.
Also, pango support is temporarily removed again and will be
re-implemented based on the new architecture.
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
Until now, bumblebee-status did event handling in two places with almost
identical code: in core.event (makes sense) and core.input (still makes
sense, but a bit more dubious).
Changed core.input to use core.event
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).
Expanding on the implementation in d582016, add a decorator
`core.module.every()` that allows a module to specify how often to
update the module's state.
This can still be overridden using the CLI parameter `interval`.
At least Void Linux doesn't like kill -SIGUSR<N>
Also, added some debugging to inspect state changes for modules/widgets.
Also also, fix problem with min width, if no minwidth is set
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)
