03:41 <kztx> Oh interesting I've never tried a no-bar approach.

03:44 <kztx> Do you have a screenshot of the overlay and the date/time/window notification? What shortcuts do you use for these?

06:41 <leon-p> gbrlsnchs: river-tag-overlay will likely be deprecated with the merge of the WM protocol. River will no longer know anything about tags and if a WM implements tags like river does right now, it can implement the overlay itself with the added bonus of frame perfection

12:21 <gbrlsnchs> leon-p: would it be possible to convert river-tag-overlay to use the new protocol and have it still running side by side with the main WM client?

12:21 <gbrlsnchs> kztx: let me try taking a screenshot for ya

12:29 <gbrlsnchs> kztx: I updated the image in my dotfiles README: https://git.sr.ht/~gbrlsnchs/dotfiles

12:35 <gbrlsnchs> somehow not having a clock visible all the time made me less anxious

12:35 <gbrlsnchs> when I want to know what time it is, I just press the hotkey to show that notification

12:40 <sewn> ifreund: I'd love to help in the dwm implem

12:40 <sewn> or maybe test or use or whatever because I'm not really good at it

13:10 <kztx> gbrlsnchs: Pure vibes, love it. Thanks!

16:01 <Monko> is there a guide for noobs step by step how to make a minimal de . to be able to click on shortcuts on the desktop and move windows with the mouse, or at least to be able to at least somehow use, because all I have now is a blue background and a terminal

16:28 <Monko> I hope someone replies. ill read later in the logs because this site throws me out

16:29 <kaisan> Monko: the intention of river, and sway, and other wm's was to remove the mouse from the equation. Fast switching, fast views, less travel, less muscle movement, gah, use a proper IRC client on your device, or install thelounge somewhere :)

16:39 <ifreund> kaisan: no gatekeeping IRC please, the webclient + logs link in the topic are a fine way to use this channel

16:53 <kaisan> apologies. I was half way my sentence when the disconnect happened. It triggered me.

17:02 <leon-p> gbrlsnchs: no. the new protocol only communicates window management between WM and river. Communicating state between desktop widgets and WM is out of scope, especially since neither river nor the protocol will know anything about tags. The word "tag" will not appear in the protocol, they are merely an implementation detail up to the WM. A WM could do something completely different if it wanted

17:02 <leon-p> as such, communicating state between WM and a desktop widget program will require its own IPC

17:03 <leon-p> however, at that point you really should just integrate the overlay directly into the WM. It's trivial code and you gain nothing but additional complexity by having it in a separate process

17:04 <leon-p> anyone can fork river-tag-overlay and add some custom IPC of course, but that is up to that person

17:06 <leon-p> Monko: there is no step-by-step guide. What you want is possible, however the software required to do it does not exist yet. F.e. you'd need a layer shell client for desktop icons and I don't think anyone has written one.

17:07 <leon-p> however, there is a guide to set-up river. it won't be exactly what you describe, but perhaps it helps: https://leon_plickat.srht.site/writing/river-setup-guide/article.html

19:50 <ifreund> kaisan: all good :)

21:09 <sewn> sorry if ive asked this before: in the context of zriver_status_manager_v1, can multiple seats have a single wl_output?

21:27 <ifreund> sewn: river doesn't support multiple seats and won't until after that protocol is gone, so don't worry about it :D

21:28 <sewn> wait, so all that multi seat handling in my wayland applications is pointless?

21:33 <ifreund> no, you are preparing for the future when river supports multiple seats and making sure things work on other compositors which already do

21:33 <ifreund> my comment is only about this soon to be removed river-specific protocol