When pressing the middle mouse button (and it's not assigned to any
other functionality), the module (i.e. all widgets of that module) will
disappear and be replaced with the module's icon (or prefix, as
fallback) and an ellipsis.
fixes#264
instead of terminating the whole status bar when an error occurs, just
show a (truncated) error for that single widget.
this should also enable auto-recovery if the module returns to a "good"
state, but that hasn't been tested yet.
see #221 and #222
Add a generic mechanism to set a specific interval (in minutes, as this
is primarily intended for modules that want to "slow down" updates).
This gives *all* modules the parameter "interval" and allows each module
to set the default interval using the method "interval(<value>) in the
module constructor.
see #220
Add a new parameter engine.workspacewrap (default to true) that, if set
to false, makes the workspace change via mouse wheel stop when hitting
the first/last workspace of an output (identical to how i3wm bar itself
behaves).
fixes#188
Add a parameter that allows the user to enable/disable workspace
scrolling via the status bar.
By default, scrolling is enabled, to disable it, add the following
parameter to your bumblebee-status invokation:
-p <other parameters> engine.workspacewheel=false
see #188
* 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
If a configuration parameter is *not* specified with -p on the
commandline, look for a INI style configuration file as fallback in
~/.bumblebee-status.conf or ~/.config/bumblebee-status.conf.
Section must be "module-parameters", like this:
[module-parameters]
github.token=<your github token>
fixes#138
Until now, manually specifying an interval did not work, as a cast to
float was missing. Now, it's possible to specify an update interval in
seconds via "-p interval=<interval>"
fixes#54
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
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
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
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
User can now use -p <key>=<value> to pass configuration parameters to
modules. For this, the module gets a "parameter()" method. Parameter
keys are in the format <name>.<key> where <name> is the name of the
loaded module. This is either the name of the module itself (e.g. "cpu")
or its alias, if the user specified it, for example:
bumblebee-status -m cpu -p cpu.warning=90
vs.
bumblebee-status -m cpu:test -p test.warning=90
see #23
Add a helper function that lists all existing modules and modify the CPU
module test so that it now generically iterates all available modules
and tests their widgets.
see #23
Allow module-specific theme information to overload "default"
configuration. I.e. it is now possible to have specific prefix or
postfix configurations for different modules. The module name is derived
for each widget from the module (__module__) from which it was
instantiated.
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
Add custom exceptions and add error handling to the engine's module
loading logic. I.e. when a non-existent module is loaded, an exception
is thrown now.
see #23
Add basic drawing of widgets. Each module instance returns a list of
widgets using the widgets() method which is then forwarded to the draw()
method of the configured output.
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
