The i3 output now has a separate thread that continuously monitors stdin
for incoming click events. The generic output class also has methods for
registering callbacks (as commands). For now, by default, scroll events
will be used to emulate the next/previous workspace.
First, cache lookups were bugged... Second, the output needs to call
data() first, everything else later.
This is a bit nasty, and I'll consider re-visiting this, but right now,
I don't see any other way, given that modules can now be iterated.
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.
Add the possibility to configure custom separators in the theme file.
These will only be used if the default i3bar separators have been
disabled. Background color will always be taken from the previous
element (to work nicely with my long-term plan, a powerline-like status
line).
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 - 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.
Prepare a framework for having modular outputs. Essentially, the main
application uses a output-type object to format strings for the
preamble, the actual data items, and a "postamble" (finalizer). The
printing of that representation, again, is up to the main application,
not the output framework.
Probably, at some point in the future, an interface class will be in
order, but right now, I want to keep it lean - seeing as for the
forseeable future, i3bar is going to be the one and only consumer of
this.
