Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.windows.x > #623 > unrolled thread

a battery monitor

Back to article view | Back to comp.windows.x

Contents

  a battery monitor Anton Antimo <anton@safunu.org> - 2026-09-01 14:28 -0300
    Re: a battery monitor Kragen Javier Sitaker <kragen@canonical.org> - 2026-09-02 00:52 -0300
      Re: a battery monitor Anton Antimo <anton@safunu.org> - 2026-09-02 12:22 -0300
        Re: a battery monitor Anton Antimo <anton@safunu.org> - 2026-09-11 16:58 -0300
    Re: a battery monitor Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-09-02 21:45 +0000
      Re: a battery monitor Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> - 2026-09-03 12:34 +0800
        Re: a battery monitor Eli the Bearded <*@eli.users.panix.com> - 2026-09-03 05:30 +0000
          Re: a battery monitor Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-09-03 21:24 +0000
            Re: a battery monitor Eli the Bearded <*@eli.users.panix.com> - 2026-09-04 02:51 +0000
      Re: a battery monitor David Brown <david.brown@hesbynett.no> - 2026-09-03 09:28 +0200
        Re: a battery monitor boltar@caprica.universe - 2026-09-03 15:55 +0000
          Re: a battery monitor David Brown <david.brown@hesbynett.no> - 2026-09-04 09:07 +0200
            Re: a battery monitor Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> - 2026-09-04 15:14 +0800
            Re: a battery monitor Lane W <cactus_DAC@yahoo.com> - 2026-09-04 05:32 -0600
            Re: a battery monitor scott@slp53.sl.home (Scott Lurndal) - 2026-09-04 14:29 +0000
            Re: a battery monitor Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> - 2026-09-04 23:17 +0800
              Re: a battery monitor boltar@caprica.universe - 2026-09-05 09:39 +0000
          Re: a battery monitor gazelle@shell.xmission.com (Kenny McCormack) - 2026-09-04 12:05 +0000
    Re: a battery monitor Anton Antimo <anton@safunu.org> - 2026-09-02 18:48 -0300

#623 — a battery monitor

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

[toc] | [next] | [standalone]

#624

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 haven’t tested the code, but I assume
you’re posting a working version, and the code looks fine at a glance,
so I'm sure it’s fine.)

Kragen

[toc] | [prev] | [next] | [standalone]

#625

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 haven’t tested the code, but I assume
> you’re posting a working version, and the code looks fine at a glance,
> so I'm sure it’s 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.

[toc] | [prev] | [next] | [standalone]

#641

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

[toc] | [prev] | [next] | [standalone]

#626

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, there’s Zenity
<https://manpages.debian.org/zenity(1)>.

[toc] | [prev] | [next] | [standalone]

#627

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).
> 
> 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 ( ;; ) _:;

[toc] | [prev] | [next] | [standalone]

#628

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

[toc] | [prev] | [next] | [standalone]

#632

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.

[toc] | [prev] | [next] | [standalone]

#633

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

[toc] | [prev] | [next] | [standalone]

#629

On 02/09/2026 23:45, 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).
> 
> 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.)

[toc] | [prev] | [next] | [standalone]

#631

On Thu, 3 Sep 2026 09:28:51 +0200
David Brown <david.brown@hesbynett.no> gabbled:
>On 02/09/2026 23:45, Lawrence D’Oliveiro 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*

[toc] | [prev] | [next] | [standalone]

#634

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 D’Oliveiro 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.

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.

[toc] | [prev] | [next] | [standalone]

#635

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 D’Oliveiro 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.
> 
> 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.
> 

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 ( ;; ) _:;

[toc] | [prev] | [next] | [standalone]

#636

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 D’Oliveiro 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.
> 
> 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.
> 
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?

[toc] | [prev] | [next] | [standalone]

#638

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 D’Oliveiro 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.
>
>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.

[toc] | [prev] | [next] | [standalone]

#639

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 ( ;; ) _:;

[toc] | [prev] | [next] | [standalone]

#640

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.

[toc] | [prev] | [next] | [standalone]

#637

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

[toc] | [prev] | [next] | [standalone]

#630

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);
}

[toc] | [prev] | [standalone]

Back to top | Article view | comp.windows.x

csiph-web