From Newsgroup: comp.windows.x

I wrote a battery monitor. The program watches its stdin for lines
containing numbers that tell what is the current percentage of the
battery. You can see a picture of it on the lower right of the image at

https://archive.org/details/x11-battery-monitor

If you compile it, then how you can see a demonstration of it running
(using bash):

for i in $(seq 100 -5 0); do echo $i && sleep 0.5 ; done | ./xbattery

So, yes, the program is more like a progress bar to be used by some kind
of shell program. Here's how I've been using it. My system has this
program called acpi, which gives me battery information:

%acpi -b
Battery 0: Charging, 91%, 00:18:43 until charged

I run CWM, the calm window manager. So from my ~/xinitrc, I run:

while true; \
do acpi -b | awk '{printf("%d\n",$4)}' | tr -d '%,' && sleep 60; \
done | xbattery 220x40-0-0 &

So, yes, xbattery.c (source code below) is able to read the desired
window geometry from the command line (as it's typical of X programs).

Be kind with criticism---that's my first one.

#include <X11/Xlib.h>
#include <X11/Xutil.h>
#include <X11/keysym.h>
#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>
#include <sys/select.h>
#include <errno.h>

void draw(Display *d, Window w, GC gc, int p,
unsigned int width, unsigned int height,
unsigned long green, unsigned long red) {
XClearWindow(d, w);

if (p < 0) p = 0;
if (p > 100) p = 100;

int howmuch;
if (p >= 100)
howmuch = width;
else
howmuch = (width * p) / 100;

if (howmuch > 0) {
if (p <= 10) XSetForeground(d, gc, red); else XSetForeground(d, gc, green);
XFillRectangle(d, w, gc, 0, 0, howmuch, width);
}
}

int main(int argc, char *argv[]) {
Display *d = NULL; Window w = 0; GC gc = NULL;
XClassHint *ch = NULL; XSizeHints *hs = NULL; int exit_code = 0;

d = XOpenDisplay(NULL);
if (!d) {
fprintf(stderr, "cannot open X display\n");
return 1;
}

int s = DefaultScreen(d);

/* Variables x, y store the position of the window on the screen.
Variables width and height store the size of the window.
Variable g stores the bitmask produced by XParseGeometry. */
int x = 10, y = 10; unsigned int width = 300, height = 50; int g = 0;

if (argc > 1) {
g = XParseGeometry(argv[1], &x, &y, &width, &height);
if ((g & XValue) && (g & XNegative)) {
x = DisplayWidth(d, s) - width - abs(x);
}
if ((g & YValue) && (g & YNegative)) {
y = DisplayHeight(d, s) - height - abs(y);
}
}

/* We've decided to use no border. But if you were to specify a
border tomorrow, it would be black. */
w = XCreateSimpleWindow(d, RootWindow(d, s), x, y, width, height, 0,
BlackPixel(d, s), WhitePixel(d, s));
if (!w) {
fprintf(stderr, "cannot create window\n");
exit_code = 1;
goto cleanup;
}

/* The name of the window. That's relevant to CWM, for example, so
that it can ignore the window and let it stand an applet. */
XStoreName(d, w, "xbattery");

ch = XAllocClassHint();
if (!ch) {
fprintf(stderr, "no memory for XClassHint\n");
exit_code = 1;
goto cleanup;
}

ch->res_name = "xbattery";
ch->res_class = "XBattery";
XSetClassHint(d, w, ch);
XFree(ch);
ch = NULL;

/* Here we annotate information to be read by the system's window
manager. It says for example what position we wish the window
to have. */
hs = XAllocSizeHints();
if (!hs) {
fprintf(stderr, "no memory for XSizeHints\n");
exit_code = 1;
goto cleanup;
}

if (g & XValue) hs->flags |= USPosition;
if (g & YValue) hs->flags |= USPosition;
if ((g & WidthValue) || (g & HeightValue)) hs->flags |= USSize;
hs->x = x;
hs->y = y;
hs->width = width;
hs->height = height;
XSetWMNormalHints(d, w, hs);
XFree(hs);
hs = NULL;

/* Here we set the events we are interested in getting. */
XSelectInput(d, w, ExposureMask | KeyPressMask | StructureNotifyMask);

/* This tells X to actually paint the window on screen for the first time. */
XMapWindow(d, w);

/* The graphics context is memory the X server keeps for knowing
how to draw elements on windows such as the size of the pen, the
color of paint and so on. */
gc = XCreateGC(d, w, 0, NULL);
if (!gc) {
fprintf(stderr, "no memory for XCreateGC\n");
exit_code = 1;
goto cleanup;
}

/* The use of a color map here exposes a bit of the design of X. */
Colormap cmap = DefaultColormap(d, s);
XColor screen_col, exact_col;
unsigned long green, red;

if (XAllocNamedColor(d, cmap, "green", &screen_col, &exact_col))
green = screen_col.pixel;
else
green = BlackPixel(d, s);

if (XAllocNamedColor(d, cmap, "red", &screen_col, &exact_col))
red = screen_col.pixel;
else
red = BlackPixel(d, s);

int x11_fd = ConnectionNumber(d);
int percentage = 90;
draw(d, w, gc, percentage, width, height, green, red); XFlush(d);

for (;;) {
fd_set in_fds; FD_ZERO(&in_fds);
FD_SET(STDIN_FILENO, &in_fds); FD_SET(x11_fd, &in_fds);

int max_fd = (STDIN_FILENO > x11_fd) ? STDIN_FILENO : x11_fd;

if (select(max_fd + 1, &in_fds, NULL, NULL, NULL) < 0) {
perror("select: "); exit_code = 1; goto cleanup;
}

if (FD_ISSET(STDIN_FILENO, &in_fds)) {
char buf[16]; int val;
if (fgets(buf, sizeof buf, stdin) != NULL) {
char *endptr; errno = 0;
unsigned long ulval = strtoul(buf, &endptr, 10);
if (endptr == buf || errno == ERANGE || ulval > 100) {
fprintf(stderr, "Oops; invalid input or out of range (0--100); trying again...\n");
continue;
}
val = (int) ulval;
percentage = val;

fprintf(stderr, "Read a line with number %d.\n", val);
draw(d, w, gc, percentage, width, height, green, red);
XFlush(d);
} else {
fprintf(stderr, "EOF; exiting gracefully...\n");
exit_code = 0;
goto cleanup;
}
}

if (FD_ISSET(x11_fd, &in_fds)) {
/* X is notifying us of something. We keep on extracting events
with XNextEvent while XPending says there's more. */
while (XPending(d)) {
XEvent e;
XNextEvent(d, &e);
if (e.type == ConfigureNotify) {
width = e.xconfigure.width;
height = e.xconfigure.height;
}
if (e.type == Expose || e.type == ConfigureNotify) {
draw(d, w, gc, percentage, width, height, green, red);
}
if (e.type == KeyPress) {
KeySym keysym = XLookupKeysym(&e.xkey, 0);
if (keysym == 'q') {
fprintf(stderr, "Quitting...\n");
goto cleanup;
}
}
}
}
}

cleanup:
if (hs) XFree(hs);
if (ch) XFree(ch);
if (gc) XFreeGC(d, gc);
if (w) XDestroyWindow(d, w);
if (d) XCloseDisplay(d);
return exit_code;
}
Followup-To: comp.windows.x
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.windows.x

Anton Antimo <anton@safunu.org> writes:

So, yes, the program is more like a progress bar to be used by some kind
of shell program. Here's how I've been using it. My system has this
program called acpi, which gives me battery information:

%acpi -b
Battery 0: Charging, 91%, 00:18:43 until charged

I run CWM, the calm window manager. So from my ~/xinitrc, I run:

while true; \
do acpi -b | awk '{printf("%d\n",$4)}' | tr -d '%,' && sleep 60; \
done | xbattery 220x40-0-0 &

This is a good idea!

X-Windows makes it a lot more trouble to write than it really ought to
be. In theory, it ought to be doable in much less code, but X really
makes your life hard there. (I havenrCOt tested the code, but I assume yourCOre posting a working version, and the code looks fine at a glance,
so I'm sure itrCOs fine.)

Kragen
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.windows.x

Kragen Javier Sitaker <kragen@canonical.org> writes:

Anton Antimo <anton@safunu.org> writes:

So, yes, the program is more like a progress bar to be used by some kind
of shell program. Here's how I've been using it. My system has this
program called acpi, which gives me battery information:

%acpi -b
Battery 0: Charging, 91%, 00:18:43 until charged

I run CWM, the calm window manager. So from my ~/xinitrc, I run:

while true; \
do acpi -b | awk '{printf("%d\n",$4)}' | tr -d '%,' && sleep 60; \
done | xbattery 220x40-0-0 &

This is a good idea!

But take notice of a bug in this script above. With the &&-conditional
above the script ends up consuming a lot of CPU if something goes wrong
in the previous pipeline. We want to sleep regardless of what happens before---or at least exit 1 if the pipeline fails.

Another bug is that the pipeline fails when you plug power in. The
percentage is not always at field number 4, so the AWK script is naive.

X-Windows makes it a lot more trouble to write than it really ought to
be. In theory, it ought to be doable in much less code, but X really
makes your life hard there. (I havenrCOt tested the code, but I assume yourCOre posting a working version, and the code looks fine at a glance,
so I'm sure itrCOs fine.)

It's a working version.

Yeah---it's surprising how much code we end up writing for such a
hello-world, but we know it's code that must be written. I suppose
that's why people write higher-level graphical toolkits, but they
wouldn't teach me as much as Xlib does.
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.windows.x

On Tue, 01 Sep 2026 14:28:40 -0300, Anton Antimo wrote:

So, yes, xbattery.c (source code below) is able to read the desired
window geometry from the command line (as it's typical of X
programs).

Instead of writing all that C code, why not using a preexisting
GUI utility that can display simple widgets like progress bars,
under the control of a shell script?

kdialog <https://develop.kde.org/docs/administration/kdialog/> is one
I have used. Or for GTK, thererCOs Zenity <https://manpages.debian.org/zenity(1)>.
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.windows.x

On 03/09/2026 5:45 AM, Lawrence DrCOOliveiro wrote:

On Tue, 01 Sep 2026 14:28:40 -0300, Anton Antimo wrote:

So, yes, xbattery.c (source code below) is able to read the desired
window geometry from the command line (as it's typical of X
programs).

Instead of writing all that C code, why not using a preexisting
GUI utility that can display simple widgets like progress bars,
under the control of a shell script?

Dear Lawrence,

What kind of /moron/ are you? Can't you understand that Anton is writ-
ing his code for his own amusement and education?


Don't let me catch you posting in comp.lang.c until you've thoroughly apologized to the fellow!
--
Johann | email: invalid -> com | http://www.myrkraverk.com/blog/
I'm not from the Internet, I just work there. | via Easynews.com https://bsky.app/profile/myrkraverk.bsky.social | for ( ;; ) _:;
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.windows.x

The original post had a "Followup-To: comp.windows.x" at the end of the
source. I presume that was the intention, so I've trimmed newsgroups.

In comp.windows.x, Johann 'Myrkraverk' Oskarsson wrote:

On 03/09/2026 5:45 AM, Lawrence D'Oliveiro wrote:

On Tue, 01 Sep 2026 14:28:40 -0300, Anton Antimo wrote:

So, yes, xbattery.c (source code below) is able to read the desired
window geometry from the command line (as it's typical of X
programs).

Fun. An obvious improvement would be to allow colors to be set on the
command line, or as XResources, instead of being hard coded. Also maybe
be able to set the color change threshold. I use a solid green
background for my root window. It's not the same shade as your green,
but close enough. An advanced option would be to have a rotation. Tall
or draining right instead of the left.

When I have needed a standalone battery monitor, I used the system file
with battery status and displayed a number in Lemonbar:

https://github.com/X11-good-tools/lemonbar

Which works like your tool, taking content on stdin and displaying it, refreshing when there is a line of input.

And used /proc/acpi/battery/ files for data. It seems that's an older
pattern, and /sys/class/power_supply/ files are used now:

$ cat /sys/class/power_supply/BAT1/status
Charging
$ cat /sys/class/power_supply/BAT1/charge_now
3673000
$ cat /sys/class/power_supply/BAT1/charge_full
4220000
$ cat /sys/class/power_supply/BAT1/alarm
420000

The /sys/class/power_supply/BAT1/uevent file exposes most of settings
in a way suitable for eval-ing in a shell script.

$ grep -i charg /sys/class/power_supply/BAT1/uevent POWER_SUPPLY_STATUS=Charging
POWER_SUPPLY_CHARGE_FULL_DESIGN=4265000
POWER_SUPPLY_CHARGE_FULL=4220000
POWER_SUPPLY_CHARGE_NOW=3673000

Instead of writing all that C code, why not using a preexisting
GUI utility that can display simple widgets like progress bars,
under the control of a shell script?

Dear Lawrence,
What kind of /moron/ are you? Can't you understand that Anton is writ-
ing his code for his own amusement and education?

Lawrence is the sort of guy who always wants to have a reply.

Elijah
------
does not expect useful replies from Lawrence on a regular basis
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.windows.x

On 02/09/2026 23:45, Lawrence DrCOOliveiro wrote:

On Tue, 01 Sep 2026 14:28:40 -0300, Anton Antimo wrote:

So, yes, xbattery.c (source code below) is able to read the desired
window geometry from the command line (as it's typical of X
programs).

Instead of writing all that C code, why not using a preexisting
GUI utility that can display simple widgets like progress bars,
under the control of a shell script?

The OP wrote a cross-post that was devoid of any C relevant content or question for comp.lang.c. But he helpfully set follow-ups to a group
that presumably /is/ relevant - comp.windows.x. We already suffer from
far too many rambling off-topic threads, and suffer even more from some
of the obnoxious trolls that have followed. (To be clear, I am /not/
counting the OP here!) If you want to give the OP advice on writing gui programs for X, that's great - but please do so in a group that is appropriate, and which the OP clearly thought was appropriate.

(For those in the other groups listed who might be wondering -
comp.lang.c is about the C /language/ - the language and the standards.
Just because a program happens to be written in C, does not mean it is relevant or topical in the group, any more than a random post written in
the English language is topical for linguistics.languages.english.
There are millions of lines of C code written every day, and they cannot
all be topical in a single group. But if anyone wants to discuss
details of the language itself, comp.lang.c is the place to be.)




--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.windows.x

Anton Antimo <anton@safunu.org> writes:

I wrote a battery monitor. The program watches its stdin for lines containing numbers that tell what is the current percentage of the
battery. You can see a picture of it on the lower right of the image at

https://archive.org/details/x11-battery-monitor

If you compile it, then how you can see a demonstration of it running
(using bash):

for i in $(seq 100 -5 0); do echo $i && sleep 0.5 ; done | ./xbattery

So, yes, the program is more like a progress bar to be used by some kind
of shell program. Here's how I've been using it. My system has this
program called acpi, which gives me battery information:

%acpi -b
Battery 0: Charging, 91%, 00:18:43 until charged

I run CWM, the calm window manager. So from my ~/xinitrc, I run:

while true; \
do acpi -b | awk '{printf("%d\n",$4)}' | tr -d '%,' && sleep 60; \
done | xbattery 220x40-0-0 &

So, yes, xbattery.c (source code below) is able to read the desired
window geometry from the command line (as it's typical of X programs).

Be kind with criticism---that's my first one.

#include <X11/Xlib.h>
#include <X11/Xutil.h>
#include <X11/keysym.h>
#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>
#include <sys/select.h>
#include <errno.h>

void draw(Display *d, Window w, GC gc, int p,
unsigned int width, unsigned int height,
unsigned long green, unsigned long red) {
XClearWindow(d, w);

if (p < 0) p = 0;
if (p > 100) p = 100;

int howmuch;
if (p >= 100)
howmuch = width;
else
howmuch = (width * p) / 100;

if (howmuch > 0) {
if (p <= 10) XSetForeground(d, gc, red); else XSetForeground(d, gc, green);
XFillRectangle(d, w, gc, 0, 0, howmuch, width);
}
}

Oops! That XFillRectangle call should be

XFillRectangle(d, w, gc, 0, 0, howmuch, height);

Let me rewrite the entire procedure (while applying this fix).

void draw(Display *d, Window w, GC gc, int p,
unsigned int width, unsigned int height,
unsigned long green, unsigned long red) {

int howmuch; XClearWindow(d, w);

if (p < 0) p = 0; if (p > 100) p = 100;
if (p >= 100) howmuch = width; else howmuch = (p * width)/100;
if (p <= 10) XSetForeground(d, gc, red); else XSetForeground(d, gc, green);

if (howmuch > 0)
XFillRectangle(d, w, gc, 0, 0, howmuch, height);
}
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.windows.x

On Thu, 3 Sep 2026 09:28:51 +0200
David Brown <david.brown@hesbynett.no> gabbled:

On 02/09/2026 23:45, Lawrence DrCOOliveiro wrote:

Instead of writing all that C code, why not using a preexisting
GUI utility that can display simple widgets like progress bars,
under the control of a shell script?

The OP wrote a cross-post that was devoid of any C relevant content or >question for comp.lang.c. But he helpfully set follow-ups to a group
that presumably /is/ relevant - comp.windows.x. We already suffer from
far too many rambling off-topic threads, and suffer even more from some
of the obnoxious trolls that have followed. (To be clear, I am /not/ >counting the OP here!) If you want to give the OP advice on writing gui >programs for X, that's great - but please do so in a group that is >appropriate, and which the OP clearly thought was appropriate.

(For those in the other groups listed who might be wondering -
comp.lang.c is about the C /language/ - the language and the standards.
Just because a program happens to be written in C, does not mean it is >relevant or topical in the group, any more than a random post written in
the English language is topical for linguistics.languages.english.
There are millions of lines of C code written every day, and they cannot
all be topical in a single group. But if anyone wants to discuss
details of the language itself, comp.lang.c is the place to be.)

Right, because usenet these days is overflowing with posts and wouldn't cope with many more.

Newflash - threads drift, stop being so uptight about it.

*sigh*

--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.windows.x

On Thu, 3 Sep 2026 05:30:37 -0000 (UTC), Eli the Bearded wrote:

Lawrence is the sort of guy who always wants to have a reply.

Technology is a means to an end, not an end in itself.
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.windows.x

In comp.lang.c, Lawrence DOliveiro <ldo@nz.invalid> wrote:

On Thu, 3 Sep 2026 05:30:37 -0000 (UTC), Eli the Bearded wrote:

Lawrence is the sort of guy who always wants to have a reply.

Technology is a means to an end, not an end in itself.

Funny how I didn't send my post to comp.lang.c but your reply ended up
there.

Elijah
------
will not post in this thread in this group again
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.windows.x

On 03/09/2026 17:55, boltar@caprica.universe wrote:

On Thu, 3 Sep 2026 09:28:51 +0200
David Brown <david.brown@hesbynett.no> gabbled:

On 02/09/2026 23:45, Lawrence DrCOOliveiro wrote:

Instead of writing all that C code, why not using a preexisting
GUI utility that can display simple widgets like progress bars,
under the control of a shell script?

The OP wrote a cross-post that was devoid of any C relevant content or
question for comp.lang.c.-a But he helpfully set follow-ups to a group
that presumably /is/ relevant - comp.windows.x.-a We already suffer
from far too many rambling off-topic threads, and suffer even more
from some of the obnoxious trolls that have followed.-a (To be clear, I
am /not/ counting the OP here!)-a If you want to give the OP advice on
writing gui programs for X, that's great - but please do so in a group
that is appropriate, and which the OP clearly thought was appropriate.

(For those in the other groups listed who might be wondering -
comp.lang.c is about the C /language/ - the language and the
standards. Just because a program happens to be written in C, does not
mean it is relevant or topical in the group, any more than a random
post written in the English language is topical for
linguistics.languages.english. There are millions of lines of C code
written every day, and they cannot all be topical in a single group.
But if anyone wants to discuss details of the language itself,
comp.lang.c is the place to be.)

Right, because usenet these days is overflowing with posts and wouldn't
cope
with many more.

Many of us would rather have just a few interesting threads, than a few interesting threads hidden amongst piles of rubbish.

I'm okay with threads drifting a bit off-topic - and even with threads
that are a bit off-topic to start with. But they should at least have
/some/ relation to C as a programming language. I'm not okay with AI
slop, endless discussions on wildly different languages, cross-posts to totally random groups, posts that are just curses and insults, or people
who jump into a community of regulars who have been there for decades
and start trying to tell them what they should and should not talk
about. (Note - that was not a reference to you.) That's just rude and anti-social.

--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.windows.x

On 04/09/2026 3:07 PM, David Brown wrote:

On 03/09/2026 17:55, boltar@caprica.universe wrote:

On Thu, 3 Sep 2026 09:28:51 +0200
David Brown <david.brown@hesbynett.no> gabbled:

On 02/09/2026 23:45, Lawrence DrCOOliveiro wrote:

Instead of writing all that C code, why not using a preexisting
GUI utility that can display simple widgets like progress bars,
under the control of a shell script?

The OP wrote a cross-post that was devoid of any C relevant content
or question for comp.lang.c.-a But he helpfully set follow-ups to a
group that presumably /is/ relevant - comp.windows.x.-a We already
suffer from far too many rambling off-topic threads, and suffer even
more from some of the obnoxious trolls that have followed.-a (To be
clear, I am /not/ counting the OP here!)-a If you want to give the OP
advice on writing gui programs for X, that's great - but please do so
in a group that is appropriate, and which the OP clearly thought was
appropriate.

(For those in the other groups listed who might be wondering -
comp.lang.c is about the C /language/ - the language and the
standards. Just because a program happens to be written in C, does
not mean it is relevant or topical in the group, any more than a
random post written in the English language is topical for
linguistics.languages.english. There are millions of lines of C code
written every day, and they cannot all be topical in a single group.
But if anyone wants to discuss details of the language itself,
comp.lang.c is the place to be.)

Right, because usenet these days is overflowing with posts and
wouldn't cope
with many more.

Many of us would rather have just a few interesting threads, than a few interesting threads hidden amongst piles of rubbish.

I'm okay with threads drifting a bit off-topic - and even with threads
that are a bit off-topic to start with.-a But they should at least have / some/ relation to C as a programming language.-a I'm not okay with AI
slop, endless discussions on wildly different languages, cross-posts to totally random groups, posts that are just curses and insults, or people
who jump into a community of regulars who have been there for decades
and start trying to tell them what they should and should not talk
about.-a (Note - that was not a reference to you.)-a That's just rude and anti-social.

Interesting concept, this anti-sociality. It seems to me, it's perfect-
ly fine for /upstanding citizens/ of comp.lang.c to be /rude and anti-
social/, but newcomers such as myself get the cold shoulders.

Have you looked up the term "hypocrite" in the dictionary recently? Let
us look at an online example.

https://www.merriam-webster.com/dictionary/hypocrite

1: a person who puts on a false appearance of virtue or religion

That seems to describe you to a T, David Brown. And why are you brown?
Are your eyes also brown?

What is the origin of describing something to a T, and is it still used
in normal every day English? That's a question for alt.usage.english.

Is "hypocrite" perhaps one of these newfangled /ChatGPT vocabularies/
that Dan Cross is so enamoured [sic] of?
--
Johann | email: invalid -> com | http://www.myrkraverk.com/blog/
I'm not from the Internet, I just work there. | via Easynews.com https://bsky.app/profile/myrkraverk.bsky.social | for ( ;; ) _:;
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.windows.x

David Brown wrote:

On 03/09/2026 17:55, boltar@caprica.universe wrote:

On Thu, 3 Sep 2026 09:28:51 +0200
David Brown <david.brown@hesbynett.no> gabbled:

On 02/09/2026 23:45, Lawrence DrCOOliveiro wrote:

Instead of writing all that C code, why not using a preexisting
GUI utility that can display simple widgets like progress bars,
under the control of a shell script?

The OP wrote a cross-post that was devoid of any C relevant content
or question for comp.lang.c.-a But he helpfully set follow-ups to a
group that presumably /is/ relevant - comp.windows.x.-a We already
suffer from far too many rambling off-topic threads, and suffer even
more from some of the obnoxious trolls that have followed.-a (To be
clear, I am /not/ counting the OP here!)-a If you want to give the OP
advice on writing gui programs for X, that's great - but please do so
in a group that is appropriate, and which the OP clearly thought was
appropriate.

(For those in the other groups listed who might be wondering -
comp.lang.c is about the C /language/ - the language and the
standards. Just because a program happens to be written in C, does
not mean it is relevant or topical in the group, any more than a
random post written in the English language is topical for
linguistics.languages.english. There are millions of lines of C code
written every day, and they cannot all be topical in a single group.
But if anyone wants to discuss details of the language itself,
comp.lang.c is the place to be.)

Right, because usenet these days is overflowing with posts and
wouldn't cope
with many more.

Many of us would rather have just a few interesting threads, than a few interesting threads hidden amongst piles of rubbish.

I'm okay with threads drifting a bit off-topic - and even with threads
that are a bit off-topic to start with.-a But they should at least have /some/ relation to C as a programming language.-a I'm not okay with AI
slop, endless discussions on wildly different languages, cross-posts to totally random groups, posts that are just curses and insults, or people
who jump into a community of regulars who have been there for decades
and start trying to tell them what they should and should not talk
about.-a (Note - that was not a reference to you.)-a That's just rude and anti-social.

That's pretty good, but I'm more about luring in serial killers off the
street to skulk around with razor blades and butterfly knives, maybe a
few posters disappearing each week. Had you even considered this?

--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.windows.x

In article <117c59h$t5au$1@dont-email.me>, <boltar@caprica.universe> wrote: ...

Right, because usenet these days is overflowing with posts and wouldn't cope >with many more.

Newflash - threads drift, stop being so uptight about it.

*sigh*

That's just the way comp.lang.c is. You get used to it over time (if you
stick around enough, that is).

I know of no other newsgroup that is so like that.
--
The randomly chosen signature file that would have appeared here is more than 4-ish
lines long. As such, it violates one or more Usenet RFCs. In order to remain in compliance with said RFCs, the actual sig can be found at the following URL:
http://user.xmission.com/~gazelle/Sigs/RepInsults
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.windows.x

David Brown <david.brown@hesbynett.no> writes:

On 03/09/2026 17:55, boltar@caprica.universe wrote:

On Thu, 3 Sep 2026 09:28:51 +0200
David Brown <david.brown@hesbynett.no> gabbled:

On 02/09/2026 23:45, Lawrence DrCOOliveiro wrote:

Instead of writing all that C code, why not using a preexisting
GUI utility that can display simple widgets like progress bars,
under the control of a shell script?

The OP wrote a cross-post that was devoid of any C relevant content or
question for comp.lang.c.-a But he helpfully set follow-ups to a group
that presumably /is/ relevant - comp.windows.x.-a We already suffer
from far too many rambling off-topic threads, and suffer even more
from some of the obnoxious trolls that have followed.-a (To be clear, I >>> am /not/ counting the OP here!)-a If you want to give the OP advice on
writing gui programs for X, that's great - but please do so in a group
that is appropriate, and which the OP clearly thought was appropriate.

(For those in the other groups listed who might be wondering -
comp.lang.c is about the C /language/ - the language and the
standards. Just because a program happens to be written in C, does not
mean it is relevant or topical in the group, any more than a random
post written in the English language is topical for
linguistics.languages.english. There are millions of lines of C code
written every day, and they cannot all be topical in a single group.
But if anyone wants to discuss details of the language itself,
comp.lang.c is the place to be.)

Right, because usenet these days is overflowing with posts and wouldn't
cope
with many more.

Many of us would rather have just a few interesting threads, than a few >interesting threads hidden amongst piles of rubbish.

So drop all the groups other than comp.lang.c whenyou reply and you'll avoid continuing the thread.

--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.windows.x

On 04/09/2026 10:27 PM, Scott Lurndal wrote:

David Brown <david.brown@hesbynett.no> writes:

On 03/09/2026 17:55, boltar@caprica.universe wrote:

On Thu, 3 Sep 2026 09:28:51 +0200

<snip>

Many of us would rather have just a few interesting threads, than a few
interesting threads hidden amongst piles of rubbish.

Keep in mind that this thread is cross-posted to three different
groups.

It's the cross-posting idiots that start this; I've removed
the unnecessary groups (including comp.windows.x) from this reply.

Now now, Scott; there's on reason to be rude. The original poster
explicitly wanted followups in comp.windows.x, and you dared to over-
rule that?

What kind of moron does something like that? Can't you just be polite
and follow the wishes of the original poster? Do you /need/ to have
this conversation in comp.lang.c where it's not wanted anyway?

I've now restored comp.unix.programmer, and comp.windowsx for cross
posting purposes, and set followups to comp.windows.x. Which every-
one knows is the only proper windowing protocol in existence! Nobody
cares about Wayland anyway.

Now, when someone dares to followup on my tangent, we can keep a civil discussion with decorum and elegance in comp.windows.x. Now, as it
happens, I do not have a running X server, and have not attempted to
recreate the feat of battery monitoring. I'm sure something will turn
up, so stay tuned to a post about a /proper Unix/ on a worthwhile mach-
ine in a completely different newsgroup.


Have a nice day!
--
Johann | email: invalid -> com | http://www.myrkraverk.com/blog/
I'm not from the Internet, I just work there. | via Easynews.com https://bsky.app/profile/myrkraverk.bsky.social | for ( ;; ) _:;
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.windows.x

On Fri, 4 Sep 2026 23:17:11 +0800
Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> gabbled:

one knows is the only proper windowing protocol in existence! Nobody
cares about Wayland anyway.

Few people cared about or wanted systemd but it got pushed by the distros anyway
for [reasons]. I suspect the same will happen with Wayland on linux, at which point I'll be off to *BSD.

--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.windows.x

Anton Antimo <anton@safunu.org> writes:

Kragen Javier Sitaker <kragen@canonical.org> writes:

Anton Antimo <anton@safunu.org> writes:

So, yes, the program is more like a progress bar to be used by some kind >>> of shell program. Here's how I've been using it. My system has this
program called acpi, which gives me battery information:

%acpi -b
Battery 0: Charging, 91%, 00:18:43 until charged

I run CWM, the calm window manager. So from my ~/xinitrc, I run:

while true; \
do acpi -b | awk '{printf("%d\n",$4)}' | tr -d '%,' && sleep 60; \
done | xbattery 220x40-0-0 &

This is a good idea!

But take notice of a bug in this script above. With the &&-conditional
above the script ends up consuming a lot of CPU if something goes wrong
in the previous pipeline. We want to sleep regardless of what happens before---or at least exit 1 if the pipeline fails.

Another bug is that the pipeline fails when you plug power in. The percentage is not always at field number 4, so the AWK script is
naive.

Here's a wiser AWK joint work with tr (with the other bugs crushed).

--8<-------------------------------------------------------->8---
while true; \
do acpi -b | awk '{for (i=1; i <=NF; ++i) if ($i ~ "%") print $i} \
| tr -cd '[0-9]' ; sleep 60; done \
| xbattery 220x40-2-0 & --8<-------------------------------------------------------->8---
--- Synchronet 3.22a-Linux NewsLink 1.2