Due to a bug, when the destination was unreachable, the checking thread
would terminate, effectively keeping the widget stuck in "unreachable"
mode.
Now, enable recovery by keeping the thread running even if the target is
not reachable for some time.
Add controls that allow the user to switch to the next and previous song
in cmus, toggle shuffle and repeat. Pause/play is toggled by clicking on
the song title itself.
fixes#5
Allow the user to use all tags read by cmus (cmus-remote -Q|grep ^tag)
as part of the displayed data (plus the special 'tags' "duration" and
"position").
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.
This is now much nicer implemented to address issue #3. A user can now
have a configuration parameter mapped to a module instance (via the
module name or the instance name) with the value "left-click",
"right-click", etc., like this:
-m disk:home -p home.left-click="nautilus {instance}"
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.
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.
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.
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).
Module themes (only!) can now contain state-specific theme information -
for example, the "battery" module has different states for charging and
discharging, and those can have different prefix and postfix
configurations to indicate what is going on.
