Instead of executing an external call to "uname", use the standard
Python module "platform" to retrieve information about the kernel used.
Positive side-effect: This is portable, if i3 ever exists on Windows :P
Since requests works the same for python2.7 and python3.x, use requests
instead of urllib (which returns a string in python2.7, but byte data in
python3.0, at least).
* Use app-specific API key for bumblebee-status
* Add some parameters (location, unit, update interval)
* Make interval calculation based on time, not number of calls
Instead of having a thread that runs in the background continuously,
spawn a new one for every update interval. That speeds up the tests
quite a lot.
see #23
Show RTT measured by ICMP echo request/replies for a given host.
For that to work correctly, change the "full_text" callback for a widget
so that the widget itself is also passed as argument in the callback
method. That actually makes a lot of sense, since the widget can now be
used as a repository of state information.
see #23
Quite a lot of modules use the "if higher X -> critical, if higher Y ->
warning" idiom now, so extracted that into a common function for reuse.
see #23
Until now, as soon as a widget registered *any* callback, the default
callbacks (e.g. scroll up/down to go to next/previous workspace) didn't
work anymore, as there was a better match for the general registration
(even though not for the button).
To fix this, merge the callback registration into a flat registration,
where a key is calculated from the ID of the registrar and the
registered button.
see #23
If the computer runs on AC, display that instead of showing "100%" in
the status.
Also, if reading the charging status fails for some reason (except the
computer being on AC), go into critical state and display "n/a".
see #23
Allow modules to define aliases. This replaces the symlink mechanism
that was in place previously, because it was a bit ugly (and confused
code climate).
see #23
If a widget exists for an interface that is not there anymore (i.e. a
tunnel interface that has been removed, or a USB device that has been
unplugged), remove that widget from the list.
see #23
Re-add the NIC module with all its functionality (hopefully...).
This introduces a new concept: Instead of having separate queries for
critical and warning (which really are just another set of states), a
module can now return a list of states for each widget. All the state
information is then merged together into a single theme. So, for
instance, the NIC module can return a state saying "critical -
wlan-down", which applies the theme information for both "critical" and
"wlan-down".
see #23
I cannot get the min_width property to work right now, so in order to
fix the width of the CPU widget, pad the utilization to 3 digits (so
that even 100% aligns nicely).
see #23
The cpu module now has cpu.warning and cpu.critical thresholds. If the
CPU utilization is higher than any of those values, the widget's state
changes to warning or critical, respectively.
see #23
