Re: [dev] [dwm] New software: swm & infobar
On 11/05/24 08:34AM, Raymond Cole wrote:
> On second thought, I think that's awful in terms of readability so I've
> just renamed it "button".
I may have been hallucinating, but when I saw "butt...tock" it occured to me that
it was clearly the opposite of a tick-tok in a butt/tick duality.
I can't speak for anyone else, but for me, it helped with readability.
> 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 essense, 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
I do not like the "_" prefixes in function variables, and do not care too
much about extra processes running or bar-updates.
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 approachs, 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.
Jeremy
Received on Tue Nov 05 2024 - 19:55:07 CET
This archive was generated by hypermail 2.3.0
: Tue Nov 05 2024 - 20:00:10 CET