Now, the error message includes the name of the module that was not
imported, and there's checks to ensure the "more specific" error (i.e. a
failing import *inside* the module) "wins".
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
