Re: [dev] [dwm] New software: swm & infobar

From: Raymond Cole <rc_AT_wolog.xyz>
Date: Thu, 7 Nov 2024 05:18:18 +0000

On 24/11/05 10:55AM, Jeremy wrote:
> > I had a look at your bar program. So it has background scripts that
> > output to files independently and depends on inotify to wait for updates.
> > One of my first ideas of infobar is the same in essence, but with
> > scripts writing to FIFOs instead of files and without use of inotify.
>
> Thanks for checking it out. I think I used inotify because I didn't know
> how to write concurrent programs effectively.
>
> > But with that approach, if multiple scripts update per minute or per
> > second independently, the moment they output won't be aligned, resulting
> > in more updates of the bar. I took a different approach also for reducing
> > the number of processes and making it easier to respond to input.
> >
>
> I envy the format string in the single-script approach, because the
> bar-widgets-as-scripts necessitates:
> 50-memory.sh, 51-music.sh, 2-date.sh, 1-time.sh
>

Thank you for your appreciation and timely reply! I apologize for my
late response.

> I do not like the "_" prefixes in function variables, and do not care too
> much about extra processes running or bar-updates.
>

I would rather not have those prefixes if shell variables were scoped
(there is a "local" keyword in many shells but it isn't standardized).
The prefixes are there to avoid name collisions which could cause very
subtle bugs. The approach I took is to prefix variables within functions
with an underscore, avoid calling functions with its own variables inside
a function, and utilize positional variables in functions.

But this is obviously not the only scheme to prevent the problem, so
maybe you have better suggestions.

> The update alignment brings up an interesting topic which I've been thinking about:
> Should X clients dispose of graphical updates if they're overwritten
> shortly after?
>
> Right now, in st, before writing updates to the screen, it waits for a
> very brief period of time, to see if there are more updates from the TTY,
> and then sends the draw commands.
>
> Though there are some understandable constraints(the X client library)
> that prevent different approaches, I've been thinking that this has been
> the cause of flickering & other race conditions.
>
> I'd curious as to your thoughts on this if it is a topic of interest for you.
>

swm/dwm redraws the whole bar every time any part in the bar changes, and,
at least in my experience, unchanged parts don't flicker, so I think X
server handles graphical updates smoothly. Given that, the only source
of flickering would be a program that does something like clearing a
region right before drawing on it. Curse programs typically do that,
so virtual terminals have a very specific need for handling flickers.
Other than that, say in the case of dwm status bar, if there's flickering
I would suspect the bar program is doing something weird and wouldn't
consider it dwm's responsibility to make up for it.

That said, there are still cases where this idea is worth exploring,
but you need to be more specific about the cases of flickering & race
conditions.

Raymond
Received on Thu Nov 07 2024 - 06:18:18 CET