Waybar battery improvments

Issues & Assistance Sway
1

I think this part of the waybar config can be better improved

"battery": {
        "states": {
            "warning": 30,
            "critical": 15
        },
        "format": "{icon}{capacity: >3}%",
        "format-icons": ["", "", "", "", ""]
    },

to

"battery": {
        "interval": 2,
        "states": {
            "warning": 25,
            "critical": 15
        },
        "format": "{icon}{capacity: >3}%",
        "format-charging": " {capacity}%",
        "format-plugged": " {capacity}%",
        "format-full": " {icon}{capacity}%",
        "format-icons": ["", "", "", "", ""]

The improvements;

  • the interval time has been significantly reduced from default 60 seconds to 2 seconds, this way changes in the battery state(charging, just got plugged in, stopped charging etc) are reflected almost immediately
  • new states (plugged, full, charging) are added to properly reflect state particularly to differentiate when the battery is charging and when it isn’t.
1 Like
2

Thanks for sharing your config @Plutack. :slightly_smiling_face:

I do not like the idea of constantly polling the battery state like that because it does cost CPU and battery every time you do it. For a state that changes as slowly as the battery, it seems wasteful to be polling more frequently than every sixty seconds; typically batteries do not discharge that fast so you shouldn’t need to be constantly checking it.

A cleaner way to refresh the module during a state change would be to use a Waybar signal and tie it to a udev rule, but it doesn’t seem to be supported by the battery module unfortunately.

Still, I would prefer refreshing the whole Waybar on a plug/unplug event like that guy is doing, as opposed to relentlessly polling the battery state every few seconds.

Are all three of these needed? Asked another way, is your laptop ever plugged in but not also either charging or full? It seems like depending on how these are prioritized, one of these will never be used.

Anecdotally, I tested on my machine real quick and couldn’t get “plugged” to do anything–even when I set it alone. Have you tested this?

Also, do we really need a separate “full” symbol? The battery icon is already showing that it is full in that state (because it is graduated), and also it says “100%” next to it.

I don’t really love the idea of adding an extra icon next to the existing icon to show that it is charging, but I’m not super opposed to it either. If we were going to do that I would almost rather switch to another battery icon set like na-md-battery.

image
image1118×658 181 KB

They have a separate series of icons for a charging state that add a little lightning bolt next to the battery. So you can have 10%, 20%, 30% and so on, and then the same if it is plugged in but with the lightning bolt next to it.

image
image1104×329 117 KB

In my opinion, that seems like it would be enough. What do you think?

1 Like
3

I couldn’t figure out a way to quote comments like you did but i digress. The only reason i reduced the time was to get quick updates during a plug in event to be fair. I figured since a lower interval time is being used for network already why not for battery. I also didn’t have any context to how intensive it is although it occurred me initially it was done this way because the strain on the battery ultimately.

I digress, for some reason i couldn’t properly figure how to blockquote a reply anyways back to subject of matter, for the battery icons. I found the one presently used(i.e the fa variants) more visually appealing. i wasn’t too happy when i found out it wasn’t as fully featured as the md variant.

As for why i thought all three is needed. my thought process was as follows;

  • like i earlier mentioned, to be able to distinguish between all state more elegantly. for example, 64% plugged in and 64% discharging looks similar. To know if a battery is in fact charging, I would need to hover on the icon or check the charging indicator light in the previous config while also waiting for current state to be polled the next time. Since I wanted to keep away from my mouse i found that flow counter intuitive.

why three of that?

  • Plugged would represent state where the battery is plugged in, is not exactly full, but is also currently not charging like when the battery is high enough that charging doesn’t kick in. A nice edge case this will also cover is if there is a faulty battery.
  • Charging would represent state where the battery is plugged in, is not exactly full, but is also currently not charging
  • Full Plugged would represent state where the battery is in full capacity indicating time to unplug

plugged
charging
full

I also found this issue in waybar repo so there probably is an issue with how I have implemented.

4

grafik
grafik834×208 38.9 KB

  1. Select the text and the pop up window appears.
  2. Now simply press Quote. Done.

Regarding your feedback.
We handle it here in such a way that each maintainer builds his DE according to his needs and the users adapt it to their needs.
If you want to share your solution with others, there is the possibility that you create a tutorial here, perhaps with a script that exchanges the corresponding values.

grafik
grafik915×283 57.2 KB

I personally don’t like this pink on dragonized KDE, so I change it to blue.
Here is an ephemeral variant, which is obsolete after an update.

sudo sed -i 's/c50ed2/226b99/g' /usr/share/themes/Sweet-Dark/gtk-3.0/gtk-dark.css
sudo sed -i 's/c50ed2/226b99/g' /usr/share/themes/Sweet-Dark/gtk-3.0/gtk.css

grafik
grafik751×232 36.7 KB

I think as long as it’s not about bugs the maintainer should decide what to change. :slight_smile:

Regarding your issue link, unlike my servers, I sit in front of my notebooks, so why do I need a special indicator that it’s still connected to the charger on 100%?
I can see that :wink:
In my personal case, I never charge up to 100% but only up to 60% because they are always connected.
As I said, it always depends on your personal circumstances and wishes.

5

fairs then. thanks for showing how to quote snippets of comments

6

Just my opinion :slight_smile:

7

The module actually changes color when it enters a charging state, to make it visually obvious if it is charging or not. etc/skel/.config/waybar/style.css · master · Garuda Linux 🦅 / Themes and Settings / Settings / Garuda Sway settings · GitLab

You can see the different colors in the screenshots you shared actually, although the fact that you did not notice this perhaps illustrates that the significance of the color is not obvious. Maybe an icon-based indication like you have suggested would be better.

I’ll give it some thought and play around with it a bit to see about incorporating additional icons to help convey the state.

What do you think about sticking the extra icon on the other side of the number? Battery icon > battery % > plug icon.

1 Like
8

wooowwww. Honestly, I didn’t notice the color change and probably wouldn’t have if you didn’t explicitly point it out.

As for layout, anything you settle for is fine definitely, I will be on the lookout if that does happen especially for the refresh udev rule you mentioned when plugged in.

I have also already defaulted back to polling at 60.

Thank you for your time and work. It is amazing!

1 Like
9

I finally put together some time to experiment with this, and ended up scrapping the style.css color-based differentiator and added a plug icon to indicate a “plugged” state instead.

image
image974×176 63 KB

I decided to keep it simple and just have the one icon for all three states (plugged, charging, full). Basically, if it’s plugged in it will get the plug. If anyone wants to take it further than that, the other states are already defined in the config now so users just need to add or change icons as they see fit.

I experimented with a udev rule to reload the Waybar on a plug/unplug event. I got it working fine, however I had some weird behavior when trying to keep the rule very generic (so it would work on any device). For example, the Waybar reloads four times consecutively for each plug/unplug event if I set the rule as ACTION=="change", RUN+="/usr/bin/killall -SIGUSR2 waybar".

After I dialed it in for my specific device, it started working pretty well but that’s obviously not going to work for other people’s hardware. People may need to set that up for themselves if they want a udev rule.

Instead, for now I just added an on-click action to reload the Waybar if you click on the battery module. That way if someone plugs in their laptop and want to refresh the module they can just click on it.

    "battery": {
        "states": {
            "warning": 30,
            "critical": 15
        },
        "format": "{icon} {capacity}%",
        "format-charging": "{icon} {capacity}% ",
        "format-plugged": "{icon} {capacity}% ",
        "format-full": "{icon} {capacity}% ",
        "format-icons": ["", "", "", "", ""],
        "on-click": "killall -SIGUSR2 waybar",
        "tooltip-format": "{}\nClick to reload Waybar"
    },

The tooltip will have a second line that mentions this new on-click action (“Click to reload Waybar”). This is kind of a bad screenshot but it looks like this:

image

All in all, I think it’s a good change. Thanks for the suggestion @Plutack!

1 Like
10

This topic was automatically closed 2 days after the last reply. New replies are no longer allowed.