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).

Issue

/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.

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").

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.

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...

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

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.

Issue

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.

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.

Sorry about the unprofessional title; I couldn't resist.

Rundown

So the whole idea here is to allow users to both:

1. print out a subset of the total hearts
   • (e.g. "I just want to know that I have more than 30% of my total battery power left")
2. print out the current battery power represented in a different base
   • (e.g. "I still want to know that I have 100% batt power, but canihaz 3 hearts instead of 10 still?").

How It'll Be

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.

Should I make a blog for ZBatt... is that even necessary?... well If I do... it'll probably be on Sourceforge.

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.

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

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?

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.

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.

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.

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:

• a config file, where options will be saved in-between sessions
• add an options item to the GUI's menu
• add an about item to the GUI's menu
• a new heart icon set
• at least 1, if not 2, shield icon sets
• plus an extra unique set I have lying around

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).

When there isn't a battery, there should be a distinct number of full hearts and empty hearts, but instead they're all empty.

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.

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.

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.

Description

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.

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 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.

Description

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.

Oh Noes!!! ZDows!!

Call me crazy, but heck, it might even be fun... in a sort of painful way.

Anyway, here's what I'm figuring:

• writing a Windows backend in C++ (lulz, so much for using the original backend, heh)
• writing a Windows frontend in C++ using either the Windows API, Qt, or GTKmm (the C++ binding for GTK)
• creating ico's for every png the GUI uses...ugggh

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.