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.
Module themes (only!) can now contain state-specific theme information -
for example, the "battery" module has different states for charging and
discharging, and those can have different prefix and postfix
configurations to indicate what is going on.
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.
