Commit graph

4 commits

Author SHA1 Message Date
Alex Kelly
c637392bd0 Correct battery modules handling of critical/warning states
The logic for the critical/warning handling on the battery modules was
applied BEFORE the discharging-<pct> logic.  This made it  possible for
those discharging states to get applied over a critical/warning and
allow a theme to override the critical/warning colors with a state of
"discharging-10", for example.

This change moves that logic after the discharging state, so that it
will always "win" if critical or warning states are set.

This also adds the "discharging" battery state to the critical/warning
check so the state will apply if the battery is not on AC power, but
would return normal otherwise.  Meaning, if the battery is "critical"
from a percentage check, but is plugged into power, the critical state
is removed.
2022-09-16 15:36:06 -04:00
Ishaan Bhimwal
a5fbc73c44 fix typo 2022-07-21 11:37:33 +05:30
Antoine Beaupré
16c4ce2ee6
handle missing battery case
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")
2022-06-20 11:34:12 -04:00
tobi-wan-kenobi
320827d577 [core] restructure to allow PIP packaging
OK - so I have to admit I *hate* the fact that PIP seems to require a
subdirectory named like the library.

But since the PIP package is something really nifty to have (thanks to
@tony again!!!), I updated the codebase to hopefully conform with what
PIP expects. Testruns so far look promising...
2020-05-09 21:22:00 +02:00
Renamed from modules/contrib/battery-upower.py (Browse further)