* A module can override the method "hidden" to specify when all it's
widgets should be hidden.
* Implement hidden for cmus and spotify
* Fix problem that cmus widgets were not displayed correctly
fixes#157
was having some problems with the current implementation as i have multiple values with the same name in sensors -u.
this way it is unambiguous and *should* just work everywhere with no lm_sensors required, though some distros might move the pseudo file elsewhere, not sure, but thats why it is configurable.
testing would be great.
also, the file is simpler too.
The module now creates a widget for each battery device it detects and
shows the status for each of them (I don't know of anyone with more than
a single battery, but if I'm overhauling the module anyhow, might as
well do it comprehensively).
fixes#117
If the current volume and mute status cannot be retrieved, the most
likely explanation is that the pulseaudio daemon is not running.
Automatically start it in such a case.
Also, add a parameter "autostart" to the pulseaudio module to disable
this behaviour in case it causes issues.
see #108
This Module Displays the Status, Song, Artist and Time of the current song played or paused in mocp.
Clicking the Modules toggles play/pause.
I'm no programmer so alteration and feedback is welcome.
Best regards, Chrugi
If data cannot be retrieved for some reason (be pretty generous about
that by catching generic exceptions), instead of terminating the whole
status bar, simply report unknown data.
see #110
Since the module requires the pulseaudio daemon to be running, in order
to query system information such as the default source/sink and the
current volume, start the daemon, if necessary.
fixes#108
A previous commit broke the traffic module by deleting widgets during
each iteration. This is fatal as the widgets contain the traffic
information from the previous iteration, for delta calculation.
Store previous traffic data in the module itself instead.
In order to (hopefully) achieve localization independence, switch from
using pactl for retrieving pulseaudio information to pacmd, which seems
to be unaffected by the LANG environment variable.
fixes#103
To avoid "stray" devices being kept in the list, empty the widgets list
during each iteration and re-populate it from the list of available
interfaces.
fixes#101
The optional parameter "states" can now be used to filter which
interfaces to display. "^" can be used for negation.
For example, to only show "up" interfaces:
-p traffic.states=up
To show all interfaces not in "down" state:
-p traffic.states=^down
fixes#98
psutil.cpu_percent() only outputs to one decimal place anyway, so the trailing 0 is useless.
The prepended 0 is also not important, will only be not 0 at 100% utilization, so why not let it be 100% then and take up one less column otherwise?
No change to default behaviour, but adds boolean to only display used rather than used, total and percentage.
To only show used memory:
-p memory.usedonly=1
OK - I admit it: Mostly for the benefit of Travis and automated testing,
which complains about the DBusException, move to a more generic
exception.
However, this is probably a good idea anyhow, because independently of
the error, setting the song to an empty string is probably the best bet.
Allow the user to filter the state of devices that should be displayed.
It's possible to use both white- and blacklists (and combinations).
For example, to only show devices in state "up":
-p nic.states=up
To only show devices that are not down:
-p nic.states=^down
fixes#84
Set the minimum width for uplink and downlink widgets to "down 1000MB",
which should be plenty, and change alignment to right (personally, I
find this looks nicer).
To not have the icons on the left side "jump around" depending on the
value, make them suffixes.
If this solution is not sufficient, alternatively, the widget itself
could perform value padding. In that case, the whole alignment and
min-width settings would be obsolete and the icons could remain on the
left side.
* use psutil instead of "ifconfig" in order to avoid external command
calls
* fix a small bug in the ascii theme (missing colon)
* show statistics per-nic
* If an exception is thrown, catch it and show a (somewhat) nice error
message in the i3bar instead of the normal content
* Add a flag "-d" for debugging into a debug log. Currently, this only
logs commandline calls as they occur and their return values, as well
as exceptions.
fixes#58
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
Create infrastructure for input event handling and add i3bar event
processing. For each event, callbacks can be registered in the input
module.
Modules and widgets both identify themselves using a unique ID (the
module name for modules, a generated UUID for the widgets). This ID is
then used for registering the callbacks. This is possible since both
widgets and modules are statically allocated & do not change their IDs.
Callback actions can be either callable Python objects (in which case
the event is passed as parameter), or strings, in which case the string
is interpreted as a shell command.
see #23
Make the format string of the datetime module configurable using the new
parameter() method in the module.
Also, restructured the setting of the config information a bit so that
the parameter() method can be used in the constructor of a module.
see #23
Until now, widgets were re-created during each iteration. For multiple,
reasons, using static widget objects is much easier, so instead of
creating new widgets continuously, modules now create the widgets during
instantiation and get the list of widgets passed as parameter whenever
an update occurs. During the update, they can still manipulate the
widget list by removing and adding elements as needed.
Advantages:
* Less memory fragmentation (fewer (de)allocations)
* Easier event management (widgets now have static IDs)
* Easier module code (widget contents can simply be the result of a
callback)
see #23
This is going to be a bit more comprehensive than anticipated. In order
to cleanly refactor the core and the engine, basically start from
scratch with the implementation.
Goals:
* Test coverage
* Maintain backwards compatibility with module interface as much as
possible (but still make modules easier to code)
* Simplicity
see #23
