This callback just makes it really hard to see for the user what is
going on. The alias the user provides should *always* match the
instance, so that it can be used in a meaningful way in the click
action, for example (otherwise, something like "nautilus {instance}"
gets really hard to interpret.
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!
Repeatedly querying the interface type the way I'm doing right now
results in "too many files open" pretty quickly. Obviously, it's a bit
of a concern that I am leaking a file descriptor somewhere, but for now,
the quickfix is to cache the type (it shouldn't change, anyhow).
All callback from a widget into a module (e.g. for retrieving the status
or the criticality state) now get a widget passed. This has the purpose
of allowing a module to store state/widget specific data somewhere. This
way, for instance, it is possible to store the interface name as part of
the widget, thus making it possible to show the status of the correct
interface.
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.
Yet another bug in the DNF module - really a troublesome one. Only call
the dnf updateinfo every interval, not every second. That significantly
reduces CPU load.
Due to name-clashing of the datetime module's "time" alias, time.sleep
didn't work (as it was looked up from the i3bumblebee module),
consequently, the DNF poll thread exited.
While at it, "beautify" the thread cancelling a bit by waiting until
the main thread is not running anymore.
* cpu+memory: Open "gnome-system-monitor"
* disk: Open nautilus
* pulseaudio: Mute/unmute, open "pavucontrol" on right-click, raise/lower
volume on mouse wheel up/down
Pass the "output" object to the modules' constructor to allow them to
define their own callbacks.
Any user-provided callbacks take precedence and override those of the
module.
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.
Add a module that periodically (by default, once every 30min) calls
"dnf updateinfo" and evaluates the results to report the number of
bugfixes, enhancements, etc.
If there's either too many pending updates, or at least one security
update, the module goes critical.
Add a module that retrieve mute status and volume (left, right, mono)
from pulseaudio. Unfortunately, this module is really, really hacky. It
invokes "pactl" multiple times to get the status and does some ugly
parsing on the output.
Overall, this is pretty brittle and prone to failure, but as I was not
able to find a decent pulseaudio library for Python... Probably, I
haven't searched hard enough, cannot believe such a thing does not
exist.
Add a new module "disk" that takes an optional parameter (the path) and
displays free & total disk space, along with the usage percentage.
Also, added Tunnel/VPN support to the themeing of the "net" module.
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.
Add functionality to provide lists of values for individual elements of
a theme (e.g. the prefix) and those will be cycled for each call.
This can be used, for example, to show a "charging" symbol for the
battery that continuously goes throw all the battery stages to "animate"
the charging icon.
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.
Format string for strftime is now configurable. Also, changed the
separator for module name vs. arguments to "::" to make it possible to
have ":" as part of the strftime format string (which is useful in most
cases).
Eventually, I'll probably have to come up with a better way, i.e. a
fully-fledged parser, and move away from "special characters", but right
now, the effort seems too much for the gain.
