Create infrastructure for input event handling and add i3bar event
processing. For each event, callbacks can be registered in the input
module.
Modules and widgets both identify themselves using a unique ID (the
module name for modules, a generated UUID for the widgets). This ID is
then used for registering the callbacks. This is possible since both
widgets and modules are statically allocated & do not change their IDs.
Callback actions can be either callable Python objects (in which case
the event is passed as parameter), or strings, in which case the string
is interpreted as a shell command.
see #23
Each widget can now return a state using the method "state()". This
string is then used to look up a theme information which is used instead
of the default or module theme, if found.
see #23
Add customized separators:
* The default separators are automatically disabled if custom separators
are used (to "just" disable the default, use empty custom separators)
* Use previous background color as their background color and the
current background color as foreground color
* Allow the separator-block-width to be configured
see #23
Allow a theme to define a "cycle" of attributes that are cycled through
on a widget-per-widget basis (e.g. for alternating the widget
background). These cycles take precedence over the default values, but
can be overridden by module-specific theme instructions.
see #23
Add a helper function that lists all existing modules and modify the CPU
module test so that it now generically iterates all available modules
and tests their widgets.
see #23
Allow module-specific theme information to overload "default"
configuration. I.e. it is now possible to have specific prefix or
postfix configurations for different modules. The module name is derived
for each widget from the module (__module__) from which it was
instantiated.
see #23
Allow sub-themes ("iconsets") to be merged into the "main" theme. That
way, effectively, it's possible to define colors and icons in separate
JSON files.
see #23
Until now, widgets were re-created during each iteration. For multiple,
reasons, using static widget objects is much easier, so instead of
creating new widgets continuously, modules now create the widgets during
instantiation and get the list of widgets passed as parameter whenever
an update occurs. During the update, they can still manipulate the
widget list by removing and adding elements as needed.
Advantages:
* Less memory fragmentation (fewer (de)allocations)
* Easier event management (widgets now have static IDs)
* Easier module code (widget contents can simply be the result of a
callback)
see #23
Add basic drawing of widgets. Each module instance returns a list of
widgets using the widgets() method which is then forwarded to the draw()
method of the configured output.
see #23
