Seems like subprocess and friends (Popen, communicate) are not so easy
to mock cleanly. Therefore, start from scratch and carefully write test
by test, until (at least) the old test coverage has been restored.
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
Somehow, the fix in the previous commit didn't work, it seems that
sometimes epoll() doesn't trigger, even if there is more data in
sys.stdin. I'm sure I'm doing something horribly wrong here.
Anyhow, as a quick fix, check for the open bracket to be sure to not
buffer the first event too long.
Re-enable the possibility to define custom mouse actions by binding
commands to "<alias|module>.<left-click|right-click|...>". These
commands are then executed as shell commands.
fixes#30
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
