Add a new "hide-able" state "mayhide" that can be utilized by modules
without warning state. This state indicates that the module *may* be
hidden by autohide, if the user configures it like this.
see #835
Add a new set of parameters to allow modules to be customly minimized.
It works like this: If a module has the parameter "minimize" set to a
true value, it will *not* use the built-in minimizer, and instead look
for "minimized" parameters (e.g. if date has the "format" parameter, it
would look for "minimized.format" when in minimized state). This allows
the user to have different parametrization for different states.
Also, using the "start-minimized" parameter allows for modules to start
minimized.
Note: This is hinging off the *module*, not the *widget* (the current,
hard-coded hiding is per-widget). This means that modules using this
method will only show a single widget - the first one - when in
minimized state. The module author has to account for that.
see #791
to trigger an update of a module (without actually triggering a mouse
interaction), use the special event "update":
bumblebee-ctl -m <module> -b update
see #784
if a module fails to load, explicitly log errors for core and contrib in
the error log, but be a bit less verbose (and less confusing) in the
module error message itself.
fixes#747
c77f3aa accidentially broke "sparse" updates (i.e. updates that do not
trigger during each update interval).
Introduce a new update parameter, "force", to model the use case "update
everything on SIGUSR1".
fixes#692
make sure that for a given event (widget/object/module, whatever), only
a *single* input event per button can be registered at one time.
the problem otherwise is with modules that re-register their widgets
with the same IDs (cmus, spotify, etc.): Each time the widget is
re-created (each intervall, typically), it re-registers an input event,
creating an always longer list of callbacks being executed when the
button is clicked (not speaking of the memory leak this introduces).
fixes#668
Make sure that iconsets used as part of a theme do *not* override
anything already existing inside the theme.
Only iconsets that are manually specified can override settings in the
theme now (because those, you typically specify on the CLI).
TODO: Write unit test for this
fixes#666
make it possible to toggle the display state of a widget between
"displayed" and "minimized" also for modules that re-create their
widgets during each iteration.
see #661
by default, allow toggling the minimized state of a widget via the
middle mouse and draw a single unicode char instead of the actual
widget, maintaining all states.
fixes#661
* First, make iconsets override anything already present in the "base"
configuration
* Second, make sure that CLI provided iconsets have higher priority than
"built-in" ones
see #648
Previous code accepted the "first" hit in a theme - particularly, if a
module is called "A" and a *different* module "B" uses "A" as state, a
widget of module B with state A would be themed as *module* A, wrongly.
Essentially, made sure that the last (most specific) themeing "wins".
fixes#647
a module can now set `self.background = True` in its `__init__()` method
to make sure its update method is invoked in a separate thread.
also, do a PoC implementation of this for the github module.
TODO: add this to dev doc
see #640
the "merge" algorithm only fills in missing elements - i.e. the most
important pieces of a data structure must be filled in first. since the
iconset specified on the CLI takes precedence over anything present in
the config, load the CLI-provided iconset *first*.
hopefully fixes#634
