Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

add EWW_BATTERY support in (free|open|net)bsd #645

Merged
merged 4 commits into from
Aug 25, 2024

Conversation

dangerdyke
Copy link
Contributor

@dangerdyke dangerdyke commented Dec 13, 2022

Description

This should add battery info support for 3/4 of the *BSDs supported as rust compile targets. I have only tested on FreeBSD, but based on the man pages of the others it should work there as well.

Usage

unchanged

Showcase

$ target/release/eww get EWW_BATTERY
{"BAT0": { "status": "high", "capacity": 61 }, "total_avg": 61}
$ uname -o
FreeBSD

Additional Notes

I was not able to add support for dragonflyBSD, as it's version of the apm command is aliased to acpiconf -i 0, which has different output and only lists the first battery. The htop source code seems to implement this for dragonfly using something to the effect of sysctl -n hw.acpi.battery.life, but I could not find documentation for that sysctl variable anywhere, and don't have a dragonfly install to test on.

Checklist

Please make sure you can check all the boxes that apply to this PR.

  • I added my changes to CHANGELOG.md, if appropriate.
  • I used cargo fmt to automatically format all code before committing

Comment on lines +189 to +191
bat.get(1).unwrap().as_str(),
bat.get(2).unwrap().as_str(),
bat.get(3).unwrap().as_str(),
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Haven't programmed in months, but I wrote magic vars.
Maybe better to use ? instead of unwrap. Magic variables are a extra, and if they break, they shouldn't take down all of eww.
And it sounds like this is going to break on a lot of bsd distributions (which is fine! Something is better than nothing here)

Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should be fine in this case, given that regex should guarantee that there will always be three captures, when the regex pattern has three capture groups, no? Or am I missing something...

@elkowar
Copy link
Owner

elkowar commented Feb 25, 2023

Could you rebase this onto latest master? I would do it, and according to github I should be able to, but it seems as though currently I can't push to your branch ^^'
Looking good though, thanks!

@dangerdyke
Copy link
Contributor Author

done!

@elkowar elkowar merged commit ee937b9 into elkowar:master Aug 25, 2024
1 check passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants