00:37 <NickH> topsykrets: using arrays for arguments can avoid a lot of pitfalls. FWIW I gave up trying to have screenshots as a onliner an instead us this https://0x0.st/X6WK.sh

03:01 <The_Buhs> __toor__ if you do wanna try out bar-less, I made a little clock thing for exactly that reason https://codeberg.org/bwbuhse/beanclock

03:02 <meidam> Can I make it possible to drag windows between monitors?

03:02 <The_Buhs> I don’t have any screenshots there yet, but it’s pretty easy to compile just to try (assuming you’re already compiling zig)

03:02 <The_Buhs> meidam no, (99% sure)

03:03 <meidam> Yeah, I can't seem to find any configuration for that either The_Buhs

03:03 <meidam> Too bad

03:04 <meidam> I can do fine with using the keybinds, but It would be nice to also be able to drag one across, like it is possible to do in probably all others

03:05 <The_Buhs> I think that will be a possibility with WMs when the WM protocol is out but that’s a while

03:07 <meidam> Okay, cool

03:08 <meidam> I'm trying river for the first time today and now feel like I have a mostly good config

03:08 <meidam> I like quite well for the most part as someone coming from dwm

03:09 <meidam> There are still some wayland quirks that I have to figure out. But that has nothing to do with river specifically. I had the same problems, when trying out hyprland

04:18 <Nickli> __toor__, something i have seen in qtile configs is they use "q,w,e,r,t" instead of 1-5 for choosing workspace, thought it was an interesting apporach for reaching

13:34 <Palanix> __toor__: I use dam by sewn. Also, you can use mpvpaper if you want an animated background picture

13:34 <Palanix> https://codeberg.org/sewn/dam

21:25 <leon-p> oh wow, the way that bar reads from stdin sure does make me uncomfortable

21:26 <leon-p> if you read into a fixed-size array, please please please do a bounds check

21:29 <vyivel> https://codeberg.org/sewn/dam/src/commit/a0c435a6f3f2a85d9a508543bdd3b58c92365b15/dam.c#L622 this? it won't read more than the array can fit

21:32 <gbrlsnchs> will WM clients integrate with external bars or will they have to render their own? asking because IIRC some unstable protocols (some of which feed bars with data) will be deprecated

21:55 <The_Buhs> gbrlsnchs: I think it's going to be up to the WM?

21:56 <The_Buhs> Pretty sure I've seen ifreund suggest that before but maybe I'm making that up

21:57 <leon-p> vyivel: I was actually thinking of the other kinds of bounds: a read returning 0 or an input starting with newline will cause the first byte to be \0. The drawing code uses a calculated text pixel length without any checking. that seemed a bit problematic to me. I wanted to try it, but the buffer pool code doesn't seem to work on my maching, welp

21:58 <leon-p> gbrlsnchs: current bars will not work with WMs, at least not without changes

21:59 <leon-p> a WM can choose to implement some sort of IPC to relay information to external desktop widgets such as bars, or draw them itself, or do nothing

22:02 <leon-p> since WMs are free to do whatever, the two best options are either that they draw it themselves, or some simple status text thex send out. WMs could have tags, workspaces, or something completely different. I can't imagine a protocol to cleanly abstract over all the possibilities

22:09 <leon-p> huh, interesting: the problem with the bars buffer pool is that it only has two buffers. in the past that would have been enough, I wonder what changed

22:34 <leon-p> hmm... know what, i think a \0 string doesn't do anything bad after all. when will I learn to not judge code when I am tired? probably never