I got to test out pbarwin.cpp on Edythe-III and found a couple of interesting side cases. The key difference between Edythe-III and Eileen-II is that the former has two batteries while the latter doesn't. That introduces issues like whether the battery enumeration will show the missing battery (it does), and what happens with respect to the different charging. I had anticipated some of these issues before hand and wrote up the mitigation, but nothing beats actually testing it on a true situation.
I had to fix one of the indicator mechanisms that I was using for the ``small battery gauge''. Here's a ghetto-photo version of how it looks like after fixing:The original way did not show any of the filled out bar if there were any such indicators, which made it quite confusing to determine in this case which battery is being charged, and at what level it was on. While fixing that, I managed to update my source code to use std::fill() over the ghetto-C way of using a for-loop to fill it up (the ``hardcore-C'' way is to use memset()).
Going back to the ghetto-picture, let me highlight the changes. I added the indicator sigils for the small battery gauge: `>' is for charging, `!' is for critical status, and `?' is for unknown status. I also have a contextual output of hhh:mm:ss that shows either the estimated time left to fully charge the current battery, or the estimated battery life left for battery discharge. It becomes ---:--:-- if the batteries are not charging/discharging, and if it is running on AC power. That was a feature that I didn't update into pbarwin.py that I could somewhat more easily pull off now.
That's about it for now. Till the next update.
No comments:
Post a Comment