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.
Individual items in the bar can now be configured with a prefix and a
suffix. It works like this:
* If there is a specific module configuration in the theme
configuration, use that (i.e. { "<modulename>": { "prefix: " a " } })
* Otherwise, if there is a configuration in the "default" section of the
theme, use that
* Otherwise, if the module object itself has a method called like the
required attribute (prefix, suffix), use that
* Otherwise, leave prefix/suffix empty ("")
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.
