Simplify the previous autohide functionality by adding a flag that lets
a module (e.g. progress) indicate that the current state should be
"revealed" (not auto-hidden).
This vastly simplifies the implementation.
see #835
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
1. Use `playerctl -f` to format, which is more powerful. This also fixes
#767, which is caused by missing a few fields of the metadata.
2. Add `playerctl.args`, so that users can choose a specific player,
etc.
3. Display nothing when there's no running player.
This is a breaking change. Users need to change `{title}` to
`{{title}}`.
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
Add a new module "layout" that will eventually evolve into the only
keyboard layout module.
Right now, it uses an external binary (get-kbd-layout) to determine the
layout of a keyboard device (because I did not manage to call libX11
with ctypes correctly).
see #788
see #790
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
By explicitly setting "cpu.percpu=True" as parameter, it is now possible
to get the CPU utilization on a per-cpu basis.
Future extension: One widget per CPU (add ID of CPU and add
warning/error state on a per CPU basis)
see #785
