User can now use -p <key>=<value> to pass configuration parameters to
modules. For this, the module gets a "parameter()" method. Parameter
keys are in the format <name>.<key> where <name> is the name of the
loaded module. This is either the name of the module itself (e.g. "cpu")
or its alias, if the user specified it, for example:
bumblebee-status -m cpu -p cpu.warning=90
vs.
bumblebee-status -m cpu:test -p test.warning=90
see #23
Allow the user to provide aliases when loading a module multiple times
so that the modules can be differentiated (e.g. for passing parameters
to a module).
see #23
This is going to be a bit more comprehensive than anticipated. In order
to cleanly refactor the core and the engine, basically start from
scratch with the implementation.
Goals:
* Test coverage
* Maintain backwards compatibility with module interface as much as
possible (but still make modules easier to code)
* Simplicity
see #23
Cycled widget styles (such as the battery charging style) were broken
until now. The reason for this: They maintain state that represents the
current cycle position (i.e. what is the current icon that is being
displayed), but that is done in a way that uses repr() on the widget
object.
Since the widget objects are re-created each time the bar is drawn, this
is a deeply flawed design.
Instead, use the instance() of the widget for now.
Hide alias concept for modules in the engine. That way, the individual
modules never get to know about whether a module has been aliased or
not.
see #23
Big oversight in my previous commits: Widgets need to be able to have
specific configurations (i.e. the path for different instances of the
"disk" module has to be different).
To account for that, it is now possible to assign an "alias" to a module
instance using ":" (for example: -m "disk:home"). This alias is then
used for the configuration parameter resolution automatically, for
example:
-m disk:home -p home.path=/home
As a consequence, parameter names in the module code are now relative to
the module, which means: shorter!
Allow the user to specify arbitrary configuration parameters from the
commandline and evaluate those in the modules (and elsewhere). Re-enable
the CPU module as a first showcase of this functionality.
Allow theme entries to be lists that are then iterated. For this
purpose, extend the Config class so that it can serve as generic store
for data items. That makes it easy to centralize code used for rotation
etc. in a single place.
