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.
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.
