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
Hide alias concept for modules in the engine. That way, the individual
modules never get to know about whether a module has been aliased or
not.
see #23
"nic.exclude" is now a parameter that can be used to have a custom list
of excluded interface prefixes. Multiple prefixes should be separated by
a comma.
fixes#26
Whenever the language is changed outside the bar, update the bar
accordingly. Also, when a new language is used, automatically append it
to the list of available languages.
User can now specify a list of languages as parameter (pipe-separated
list). Variants can also be specified by separating language and variant
with a :
For instance: -p layout.lang="us|rs:latin"
Left click moves on to the next language, right click to the previous.
Right now, there are the following caveats:
* The first entry in the list must be the language used when the bar
starts
* kxbd changes outside the bar are not picked up automatically
This one is a bit tricky:
* Clicking on an active xrandr output will disable it
* Clicking on a disabled xrandr output will enable it -> if
it is a left-click, it will put it as the left-most display
if it is a right-click, as the right-most display
Also, it will reload the i3 bars (using a script that allows
you to write custom pieces of an i3 configuration that is applied
conditionally depending on the screens you have).
It goes like this:
* Base config is in ~/.i3/config.template
* Output-specific config is in ~/.i3/config.<screen name>
* Output-specific config when other screens are also active is in
~/.i3/config.<screen>-<other-screens-in-alphabetic-order>
For instance:
$ ls ~/.i3
config.template
config.eDP1 -> will be applied to eDP1 (always)
config.VGA1-eDP1 -> will be applied to VGA1, if eDP1 is also active
config.VGA1 -> will be applied to VGA1 (if eDP1 is inactive)
fixes#19
This modules shows attached displays and their states (on or off).
Future versions of this module will order the icons by the relative
order of the screens (left-to-right) and will allow switching monitors
on and off.
see #19
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.
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.
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.
Add a plugin that displays the remaining battery power in %. This also
introduces the concept of arguments that can be passed to a module
during startup by delimiting the module name with ":", for example:
-m battery:BAT1 to query the BAT1 device.
Note that this works to an arbitray length, i.e. if a module accepts 3
parameters: -m <modulename>:<A>:<B>:<C>
The module gets the arguments as list.
Add - again a very simplistic - method for themeing the output.
Essentially, the plan is to have JSON-formatted configuration files in
bumblebee/themes/ and have a separate class for querying the config
whenever the output needs to know about semantic formatting/coloring.
Note that the theme object is stored on a per-module basis. Right now,
that doesn't have any effect (except looking particularly wasteful), but
the idea is to be able to have different themes for different modules in
the future.
Add a very simplistic framework for loading modules that query system
data. The user can provide a list of modules via an argument switch, and
the name of the module is used to look up a Python module that has to
have a class called "Module".
The outer framework (the outputs, in particular) then uses various query
methods of that class to construct a meaningful output.
