amagura / zelda-battery Goto Github PK
View Code? Open in Web Editor NEWA Legend of Zelda inspired health-bar battery meter for the CLI and GUI
License: Apache License 2.0
A Legend of Zelda inspired health-bar battery meter for the CLI and GUI
License: Apache License 2.0
OpenBSD lacks sysctlbyname
; further more, it's sysctl
values do not include a battery level in a readily used form: rather, it contains information concerning the number of watt-hours remaining, from which the battery percent level can be calculated.
Because there's no way to guarantee that (for whatever reason) vanilla acpi
or pmset
or whatever util ./configure
has found and has chosen to use for the -DZELDA_BATTERY_UTIL=\"<UTIL>\"
CPP flag, peeps should be able to explicitly specify a program/utility that should be used instead of whatever was chosen by ./configure
. However, setting POWER_UTIL
in the environment of the build does nothing. It should change the value of the ZELDA_BATTERY_UTIL
CPP flag, but it doesn't.
There's no menu for the GUI. How do people, that aren't running it from the command-line, exit out of ZBatt without actually running kill
or killall
on it?
Should I make a blog for ZBatt... is that even necessary?... well If I do... it'll probably be on Sourceforge.
Sorry about the unprofessional title; I couldn't resist.
So the whole idea here is to allow users to both:
I think No. 1 should be easy enough; the real question is No. 2—lulz, just realized what that kinda sounds like, lol!. 😆
Anyway, the real question is whether converting base 10 crap to base x will provide an accurate reading of the current battery percentage or whether just dividing the actual batt level by the desired number of hearts would be more precise.
The first option (base conversion) sounds more fun and satisfyingly clever, so I'm going to give that a shot before giving up and using plain old division.
/sys/class/power_suppy/
has changed causing ZBatt to stop working. The fix should be pretty simple, based on a cursory look at /sys/class/power_supply
: it looks like batteries are represented a little differently, but I won't know the true extent of the changes until I take a deeper look.
ZBatt is rather difficult to debug without using something like valgrind
or gdb
or rebuilding it from source with --enable-debug
; I don't think this is necessarily an issue that should be resolved directly by ZB, though: I think this should be handled either by commoner (creating a log.{c,h}
exposing a logging faculty(?)), a third party library dedicated to powerful, performant logging, or by rolling my own log library.
running ./configure --enable-generic
or ./configure --enable-native
has no effect whatsoever on the actual build process.
My laptop can't charge it's own battery, so I have an external (dedicated) charger that I bought a while ago so that I can still enjoy mobility of that my laptop (barely) offers.
So today, after I got back from hooking my battery up to its charger, I was having problems getting my wifi to work, and while trying to debug that I came across the following logs in systemd's journal (note that these are not the original logs):
-- This usually indicates a programming error in the crashing program and
-- should be reported to its vendor as a bug.
Jan 29 22:02:58 Aya kernel: zbatc[2169]: segfault at 0 ip 00007f8023169854 sp 00007fff9343fad0 error 4 in libc-2.20.so[7f8023100000+199000]
Jan 29 22:02:58 Aya kernel: zbatt[2172]: segfault at 0 ip 00007fdf67005854 sp 00007fffc8b76050 error 4 in libc-2.20.so[7fdf66f9c000+199000]
Jan 29 22:03:00 Aya kernel: zbatc[2177]: segfault at 0 ip 00007fbc9a482854 sp 00007fff6e40e1f0 error 4 in libc-2.20.so[7fbc9a419000+199000]
Jan 29 22:03:00 Aya kernel: zbatt[2180]: segfault at 0 ip 00007f91601c7854 sp 00007fff178783f0 error 4 in libc-2.20.so[7f916015e000+199000]
Jan 29 22:03:00 Aya systemd-coredump[2178]: Process 2177 (zbatc) of user 1000 dumped core.
-- Subject: Process 2177 (zbatc) dumped core
-- Defined-By: systemd
-- Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel
-- Documentation: man:core(5)
--
-- Process 2177 (zbatc) crashed and dumped core.
--
-- This usually indicates a programming error in the crashing program and
-- should be reported to its vendor as a bug.
Jan 29 22:03:00 Aya systemd-coredump[2181]: Process 2180 (zbatt) of user 1000 dumped core.
-- Subject: Process 2180 (zbatt) dumped core
-- Defined-By: systemd
-- Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel
-- Documentation: man:core(5)
--
-- Process 2180 (zbatt) crashed and dumped core.
--
-- This usually indicates a programming error in the crashing program and
-- should be reported to its vendor as a bug.
Note that the above core dumps occur every time Zsh redisplays the prompt.
What I'd like to do is setup some cool error patterns using the output of zbatt
and zbatc
to indicate which error is currently occuring, so that users won't have to get annoyed with error messages popping up every time their prompt redisplays while still allowing them to know that an error has occurred.
After looking at other projects out there that use autotools, I suspect that I'm using it wrong and over engineering ZBatt: for example, I noted that some projects seem to make use of a config.h
file that autotools produces that (I assume) contains information about missing functions, headers, and that kind of thing.
I think that if I were to make use of config.h
that I might be able to get rid of things like compat.h
and use fewer checks in configure.ac
, but who knows: I'd just like to take sometime to look into this and ensure that I'm using autotools correctly.
The CLI is working great now, but the GUI is now segfaulting now that I've placed my (now fully charged) battery back into my laptop. hmmm...
The GUI still functions when a battery is not present, but it doesn't work like it should. It should depict the borked png, but instead it rendered the quarter empty png.
Calls to pwrinf
(located in acpi.c
) from getpwr
in power.c
do not seem to check (I believe that they do at least on some level) for errors, or at least, not for the few defined errors that ZBatt has to work with: error messages should be added so that we don't have ambiguous errors messages like "No such file or directory" when the problem is actually that there isn't a power supply installed.
This is somewhat related to #13
It'd be really nice if ZBatt could handle configs so that you'd be able to change how you want your ZBatt to look without having to start your shell over, since the changes in your call to ZBatt within your shell prompt won't take effect until after you resource your shell's rcfile. Hmm....
This is something that I've been wanting for a while now; it would make debugging so much easier, since I would no longer have to remove my battery from my laptop and I could just compile ZBatt to look at directory XYZ.
I would like to remove a lot of the code that ZBatt includes with it and instead move said code into the ROLLS, a library I'm currently writing, and merely link ZBatt with said library and/or compile it statically to include said library, especially since ROLLS has a very, IMO, sophisticated manner of handling naming conflictions, or at least it is capable of letting individuals using the library the option of choosing whether to use a natively supported/implemented version of any provided function or macro instead of the implementation that ROLLS offers, in case said user would rather rely on seasoned professionals rather than on a no-name programmer, regardless of his skill level, capability, talent, or whatever.
Call me crazy, but heck, it might even be fun... in a sort of painful way.
Anyway, here's what I'm figuring:
It'll probably take forever and be a pain in the butt to test and debug, since I'll have to use a virtual machine, but it'd be so freaking awesome to show it off to my family and friends... on their computers, of course.
This is somewhat related to #25: currently, ZBatt has no support for Mac OS X systems and I honestly don't know how to query power information from Mac OS X systems. I'll need to do some research during my down time.
I believe that support for OpenBSD could be added by utilizing APM, however, I'm not entirely sure how to do that, so it may take a bit.
When there isn't a battery, there should be a distinct number of full hearts and empty hearts, but instead they're all empty.
In theory if the directory tree in /sys/class/power_supply
is deep enough: ZBatt will run out of memory and crash. I'd like to fix this so that it will be less likely to happen.
Some of the M4 macros in configure.ac rely upon knowing what kind of operating system ZBatt is being built on, and this (of course) isn't entirely portable. I'm not sure if it can be fixed, but if nothing else I'd like to at least expand the array of systems recognized by the configure script.
Typically when ZBatt encounters an error it more or less tries to hide it from the user so that they can still enjoy some of the experience of ZBatt. However, sometimes this is not what the user might want, so it would be nice to add an option that would make ZBatt actually print error messages instead of just conveying that something is wrong with an unusual power representation.
I'd like to add an options item to the GUI's menu, where people will be able to configure the GUI a bit, however, doing so will require a few things:
I'm probably gonna get into serious trouble for the shield sets, but.... it's just too cool to resist: plus, I can always take 'em down and change my commit history if *tendo sued or something. (don't want to say the name, lulz).
Related to #23
I've decided to hold off on the shield icons: I'd like to get a professional to do them for me (I don't think I'd do a very good job, lulz).
Figure out exactly what ZBatt needs in order to function, more specifically, find out what the GUI (gzbatt) depends upon so that people will know what to download and install.
Currently, the error messages in ZBatt, while informative to one informed, are still even then ambiguous. They only say what is wrong, but not why it is wrong (e.g. "a file is missing" instead of "the config file is missing").
Lulz, I'm kind of tired of how messy main.c has been getting lately, and I'd like to make a single maintenance for all of the macros and functions that I often use across projects, so I've created a common area where I can maintain said functions and macros and then pull them into whatever project I'm working on using git and that kind of crap
I have 57 % battery power presently, but the GUI shows me only have about 20% left, which is incorrect. I some math and it looks like I need to round the result of pwr.charge.raw / pwr.charge.tr
instead of just casting it to an int, or maybe add a new field to pwr.charge
and call it rnd
.
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.