Pass the "output" object to the modules' constructor to allow them to
define their own callbacks.
Any user-provided callbacks take precedence and override those of the
module.
Add a module that retrieve mute status and volume (left, right, mono)
from pulseaudio. Unfortunately, this module is really, really hacky. It
invokes "pactl" multiple times to get the status and does some ugly
parsing on the output.
Overall, this is pretty brittle and prone to failure, but as I was not
able to find a decent pulseaudio library for Python... Probably, I
haven't searched hard enough, cannot believe such a thing does not
exist.
Format string for strftime is now configurable. Also, changed the
separator for module name vs. arguments to "::" to make it possible to
have ":" as part of the strftime format string (which is useful in most
cases).
Eventually, I'll probably have to come up with a better way, i.e. a
fully-fledged parser, and move away from "special characters", but right
now, the effort seems too much for the gain.
It is now possible to add a list of theme configurations in the
"default" section called "cycle". These configuration items will be
cycled through module by module. to create "alternate style" effects.
This is *only* possible in the "default" configuration part, but any
module-specific configurations still take precedence.
Also, removed the capability of per-widget themes. That simply
complicates things and probably doesn't really bring any benefits.
Add a plugin that displays the remaining battery power in %. This also
introduces the concept of arguments that can be passed to a module
during startup by delimiting the module name with ":", for example:
-m battery:BAT1 to query the BAT1 device.
Note that this works to an arbitray length, i.e. if a module accepts 3
parameters: -m <modulename>:<A>:<B>:<C>
The module gets the arguments as list.
Add - again a very simplistic - method for themeing the output.
Essentially, the plan is to have JSON-formatted configuration files in
bumblebee/themes/ and have a separate class for querying the config
whenever the output needs to know about semantic formatting/coloring.
Note that the theme object is stored on a per-module basis. Right now,
that doesn't have any effect (except looking particularly wasteful), but
the idea is to be able to have different themes for different modules in
the future.
Add a very simplistic framework for loading modules that query system
data. The user can provide a list of modules via an argument switch, and
the name of the module is used to look up a Python module that has to
have a class called "Module".
The outer framework (the outputs, in particular) then uses various query
methods of that class to construct a meaningful output.
