Add a module that displays the status of all NICs (interface name, list
of IPs and state).
In its status, it also exposes whether it's a WiFi or a wired NIC.
For this functionality, additional code was implemented to allow a
module to add multiple elements to the bar at once. The framework calls
the module until its "next()" method return False.
Font and background colors for warning and critical elements can now be
specified using fg-warning, fg-critical, bg-warning and bg-critical.
Also, optionally, the "urgent" flag will be set towards the i3bar, if
possible.
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.
