Persistent battery status indicator

[stevesydney]

I'd like to set up an old tired laptop as a writing machine by running a command line distro of linux that boots into wordgrinder.

The only thing missing is a battery status indicator so I know when to find a plug in the cafe.

Is this interesting to others? Would it be easy to implement?

[MortenJuhl-Johansen]

How about a modern sexy version of this?

HOWTO: add battery status to bash prompt

[stevesydney]

I found a couple of comments on the WordGrinder web page also mentioning battery status, so I guess it's not a totally crazy idea.

[rogerxxxx]

Two ideas, if your using Linux terminals and not using Xorg/Wayland, can likely have an acpid script pipe something to all terminals (or just a specific commonly utilized terminal) the battery percentage once the battery approaches a critical threshold. This seems like the best idea to me currently, as the piping/printing to terminal will likely significantly interrupt the terminal characters/graphics, likely requiring a terminal printing reset.

Another idea is, if not using Xorg/Wayland and only Linux terminals, have one terminal constantly printing/monitoring the battery percentage, while using another terminal for word processing. This seems easiest, however not really fool-proof.

If using Xorg/Wayland, probably better sacrificing some of the graphical screen/display estate for monitoring applications?

As for myself, I would likely be using Linux terminals, and engineer an acpid (or apm or whatever) script for interrupting the screens/displays once a critical battery threshold has been reached. Once I started a laptop and word processing while on battery, I'm already assuming I have a finite amount of time on battery, and/or would quickly check remaining battery amount prior to working, and only requiring additional knowledge of the battery amount once critical levels have been reached.

One additional note, most distributions if I'm not mistaken, are likely setup for automatically powering-off once critical battery levels have been reached. And if not already configured, can be done so relatively easily. I have already setup my laptops for automatically powering-off once critical levels has been reached. And, typically, notice is printed to terminals just prior to automatically power-off? Only question being, is syncing performed prior to power-off, preventing data loss.

[stevesydney]

only requiring additional knowledge of the battery amount once critical levels have been reached

I think this is very sensible and would serve for most people, but I'm the kind of person that needs to make sure range anxiety isn't a factor. I'd like this setup to be a focused, mono-task, device for distraction-free writing and for me, the unknown distance to critical battery level would be a constant distraction.

But from the sounds of your detailed response, it could be taxing on the performance of WordGrinder itself to be polling for the battery status at regular intervals

[rogerxxxx]

On Tue, Nov 05, 2024 at 08:08:56AM -0800, Steve Farrugia wrote: > only requiring additional knowledge of the battery amount once critical levels have been reached I think this is very sensible and would serve for most people, but I'm the kind of person that needs to make sure range anxiety isn't a factor. I'd like this setup to be a focused, mono-task, device for distraction-free writing and for me, the unknown distance to critical battery level would be a constant distraction. But from the sounds of your detailed response, it could be taxing on the performance of WordGrinder itself to be polling for the battery status at regular intervals

I'm not the developer of this software package, however there are common design goals. Typically, the first steps for mitigating is using existing software tools versus adding something exquisite or not main function of the application. For myself, I'm pretty comfortable or assured my (acpid) scripting, once properly engineered and working, I feel I can rely upon scripts. The developer has been active for the past week or so, so I'm sure he'll evaluate too the need. Using an Internet search engine, if needed, can search for applicable acpid scripts. Another good idea, posting the same question to your Linux distribution's mailing list for help with configuring either acpid or other power management tool. Describe whether you're using Linux terminals or graphical user interface, etc... Just some tips. Hopefully this is helpful while awaiting the developer's response.

[davidgiven]

I'll admit to not being particularly keen on adding a battery meter directly as the APIs for doing so for each platform would be a nightmare. Currently the only thing which is platform-specific in WordGrinder is the new clipboard code, and that was hard enough (and I still haven't found a version for Haiku). One alternative is the ability to run a command periodically and show in the status bar. But I do think this smells rather of the kind of problem which isn't suited for doing inside WordGrinder.

I like the idea of using something like tmux or screen to set up a single-line window which contains the battery meter, and possibly any other tool; this would be like an extra status bar at the bottom (or top) of the screen. It is a bit more cluttered and detracts from the minimalist experience.

Can tmux be configured to show something on top of another window? That way the extra information could be overlaid on unused parts of the WordGrinder display.

[rogerxxxx]

I know wordgrinder's interface seems to want to mimic a typical typewriter, and/or for explicit focus on what's being typed. If so simulating a typewriter, there were areas on the old electronic typewriters for status lights. Rather than focus on just adding a feature for one specific status of the battery, might add a more generic option for including status of battery, number lock, maybe word count, ... etc.

But again, this would take time; and we already have other options.

GNU Screen does augment a bottom area for tab names, I believe GNU Screen dot config screenrc has this function named hardstatus. So there are other options. They just take time for the user to research and implement, and then hopefully documenting on a Wiki page so others can more easily implement themselves. (eg. acpid script, GNU Screen script, ...)

Think the crux or one fix for the problem, documenting the above options thoroughly somewhere common, so users not fluent with computers or have the time for tinkering, can easily implement.

Another option, I see wordgrinder does already have word count at the bottom right, would be adding an additional interface for scripting a function (eg. battery percentage stdout/print-out), printing the script output to an area within the wordgrinder status bar. Something like what conky cli does for printing whatever we want within our status line within the DWM desktop.

Shrugs... neither for or against this, and just trying to put some helpful ideas out there.

Think a wiki or internet page thoroughly documenting an acpid script would be quickest and likely sufficient once others see how easy to implement. However, I only have acpid shutting down, and not sure if it prints/stdout critical percentage on the terminal. Rarely have used battery nowadays.

[somnolik]

FWIW, I've just hacked in a battery readout as a menu command that just reads in /sys/class/power_supply/BAT0/capacity and emits the value formatted as a NonmodalMessage - so I just press ALT+F then L and I get the message 58% battery left.

I feel this is something that's easy enough to do for a specific setup, but a nightmare to do in a generic, OS-independent way. Having the option to edit custom menu entries with custom Lua functions without recompiling could be a nice compromise... just an idea. I haven't checked if enough of the Lua parser is left in the compiled binary to make this feasible.

Context: I've set up a dedicated OS using https://buildroot.org/ that boots directly into wordgrinder and powers down on program exit, no network, no audio, as distraction-free as possible. Having a terminal multiplexer running for displaying the battery status on that machine would kinda run against the design idea. (Feels incredibly like a DOS throwback, btw. Can recommend.)