Load configuration files from a number of places and, if they exist, use
the settings there as baseline settings that can be overwritten by more
specific source (the modules themselves and the CLI `--parameter`
option).
TODO: document this
to make it easier to trigger events programmatically, the IDs for
modules are not auto-generated UUIDs anymore, but rather the module name
(which has to be unique, anyhow).
make it possible to specify the minimum width of all widgets via:
`-m cpu -p cpu.theme.minwidth=20`
or
`-m cpu -p cpu.theme.minwidth=aaaaaa`
multiple widgets are comma-separated (missing entries will have no
minwidth)
`-m sensors2 -p sensors2.theme.minwidth=10,20,10`
see #606
TODO add to documentation
to make errors easier to diagnose, do not scroll them, but instead fully
show them.
also, re-introduce the supplementary fields for the dwm bridge, kudos to
@somospocos
Re-enable the -f | --logfile parameter, but still default to logging to
stderr.
Also, add a "debug" module that is automatically displayed if a bar is
run in debug mode (thanks to @bbernhard for the excellent suggestion)
fixes#614
first, this fixes#607
also, i think it slightly simplifies code to make "simple" stuff like
names, etc. attributes instead of methods all the time.
so, expect this to be extended to other components, as well.
Until now, using a list as prefix/suffix didn't work as expected,
because the corresponding method for retrieving the value was called
multiple times, and each time, the next icon would be retrieved.
Changed the logic inside the theme to only update the indices every time
that an actual update was happening.
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
