I run the same bumblebee-status configuration on my laptop and my
workstation. On my laptop, the upower module works fine: it says "ac"
when plugged in, charging, all that stuff is great.
But on my workstation, it's completely broken: it thinks there's a
battery (which is a mistake: there is no battery at all, apart maybe
from the CMOS battery, but that's not covered by upower), and it
thinks it's discharged, which makes a very noisy warning in the bar.
Now maybe there's something wrong with dbus, Debian, the kernel,
Linux, or some thing else in the stack. All I know is that
`self.power.get_display_device()` returns something like a valid
dbus object here and from there it confuses the heck out of the
module.
So this just adds a function to check if the actual device we're
talking about is actually present, and bails earlier otherwise.
Before: battery logo and "0% 00:00m!", all marked as critical ("red")
After: "ac" with the plugged in logo, not marked critical ("black")
* util.popup requires tkinter to be installed (in order to display
popups). As most people will probably use the default configuration
of the pulseaudio module (where the popup is disabled) and in order
to avoid breaking existing setups, we catch import errors and just log
them.
* added possibility to show currently selected default device in the
statusbar (default: off)
* allows to override the left mouse button click with a different
action (e.g open popup menu to change the current default device)
This reverts commit eb51a3c1c7, reversing
changes made to c57daf65ce.
Instead of creating a separate module, the changes will be integrated
into the pulseaudio module.
When registering an event (especially mouse events), if the parameter
is a valid method in the Module, execute that with the event as
parameter.
Add this in the core.spacer module as an example.
fixes#858
see #857
When closing a popup window when the mouse leave the area (default
behaviour, unfortunately), the main "show()" got stuck in an infinite
loop.
Fix that by setting running to False when exiting.
fixes#844
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
