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
