09:43 <flower_> ok riverwm interesting, maybe my new wm after dwm and dwl. But I probably will miss the deck layout: https://dwm.suckless.org/patches/deck/

09:43 <flower_> I read a bit about tags, do you guys set those from the command line, how does that work at runtime?

09:48 <Nickli> i assume Deck is similar to Tabs in i3/sway

09:49 <Nickli> everything can be set in the init file

09:59 <flower_> No it's not similar to tabs

10:00 <flower_> or at least not the same

10:03 <flower_> I use it all the time

10:04 <flower_> one of the not-main-windows takes all the not-main-space. The other are hidden.

10:07 <flower_> I don't think I can do without it ... hm

10:08 <flower_> so you can't have a two page view in river when you've more then two windows open in a tag, while such a dual window layout it quite common usage on desktops

10:08 <Nickli> sounds a little bit like what Herbstluft is known for

10:09 <flower_> nice name at least :)

10:10 <Nickli> default in RiverWM is the main/stack layout (forget the official name)

10:11 <Nickli> and the window management is fairly barebones so far and on purpose, until more hooks can be used by third party managers

10:12 <flower_> hm yep, monocle would be nice too

10:13 <flower_> and a suckless patch system like dwm? I might prefer that as long term maintainance of those subprojects looks uncertain to me

10:14 <flower_> looking at those, quite of them seems already not very active, but I could be wrong

10:14 <flower_> and you're dealing with multiple programming languages, instead of one (c / zig)

10:15 <flower_> deck is a dwm-layout which is inspired by the TTWM window manager. It applies the monocle-layout to the clients in the stack. The master-client is still visible. The stacked clients are like a deck of cards, hence the name.

10:17 <Nickli> guess many are waiting on #1100 releases which enables more control over windows

10:20 <flower_> #1100?

10:20 <Nickli> https://codeberg.org/river/river/pulls/1100

10:24 <flower_> rivertile-top -bottom is nice though

10:26 <flower_> I'm working with multiple graphical music creation applications and a 'session manager', then it's nice to have the session manager on one half and one of the music applications on the other. The session manager is also capable of showing and hiding the applications, so this is quite a dynamic workflow. I found the deck patch to be a good fit for this.

10:28 <flower_> but also when programmming, I use it. I use it a lot actually and also monocle, which prefer above fullscreen because of the statusbar (waybar atm)

10:30 <Nickli> you can look through https://codeberg.org/river/wiki/src/branch/master/pages and see if anything works for you

10:33 <flower_> heh, I'm a fan of dwm and the suckless approach with the patches, once you've your setup you don't have to touch it again for years, but dwl crashed on my recently. I think zig is a interesting choice.

10:34 <flower_> maybe I can patch river with deck functionalit one day

10:34 <flower_> that deck patch is quite small it seems

10:35 <ifreund> flower_: it would be trivial to patch an existing layout generator to support that deck layout

10:35 <ifreund> the point of layout generators is that you dont have to patch river itself

10:36 <flower_> ifreund: I suck at math ;) Ok, I might dive into it, as I'm intending to learn Zig a bit anyway

10:36 <sewn> flower_: you can report the issues!

10:37 <ifreund> you dont even need to learn zig, you could use C

10:37 <flower_> My plan was to do C after zig ;)

10:38 <sewn> learning zig after c was really nice, makes me want to drop c entirely

10:39 <flower_> I tried some c, but those course books don't seem to cover memory that well, or I missed that, but reading some docs about Zig and I think I see how it works now with global, stack and heap.

10:41 <ifreund> Alright, python then :P

10:41 <flower_> Programmers are not always good educators probably, they seem to assume that a lot of what they do everyday is common for other people. Giving kids the task to make a loop, while forgetting to explain what a loop is for instance.

10:42 <flower_> But that seems to have improved quite a bit recenlty

10:42 <sewn> learning by doing is effective;

10:42 <flower_> Been there, then switched to Go which is nice to work with

10:43 <flower_> Ok a deck patch might be a nice step in the learning curve

10:43 <sewn> why not a layout generator?

10:45 <flower_> because that's probably a much bigger task, also conceptually, having a logic which works for different layouts

10:46 <flower_> but I didn't dive into it yet, I just build river, started it, made waybar work, looked if it would crash like it does in dwl and jumped into the irc channel

10:46 <sewn> well, deck is a different layout is it not? you'll still have to learn the logic for that, the rest of the task is fairly easy

10:47 <sewn> rivertile isn't as simple as dwm tile()

10:47 <flower_> and then you think about zig for such a layout generator?

10:47 <sewn> doesnt have to be zig!

10:48 <flower_> I saw something written in python, no that's not what I want with the dependency and deprecation hell

10:48 <sewn> doesn't have to be python either

10:48 <flower_> so zig I guess or Go :)

10:49 <sewn> I think you can try to do it in Go and slowly rewrite it as zig

10:49 <flower_> yep indeed, then even python would be a option

10:50 <sewn> well you just said you dont want the dependency hell :0

10:51 <flower_> ok, but first I've some other things on the table. Will login to dwl for now as I feel handcuffed or braincuffed without 'deck'

10:54 <sewn> is it that good?

10:57 <flower_> for me it is apparently

11:48 <flower_> one feature I like in sway is how you can easily resize a window with the mouse.

11:48 <flower_> Resizing in general works better in dwm / river though, as in sway you have to set resize mode IIRC

11:50 <flower_> But for my workflow, multiple modular music creation applications, such a resize method is nice

11:50 <flower_> anything similar in river or it's layout generators?

11:53 <flower_> the way sway is positioning windows doesn't work for me though, then dwm style works much better for me

18:55 <vimproved> ifreund: fyi, i'm currently investigating a weird crash that happens whenever I open a native wayland flatpak application. it seems to be related to some FFI issues, but i'm not entirely sure. here are some relevant logs from lldb just in case you can figure out what's going on quicker than I can: https://paste.gentoo.zip/UWKvwPN2

18:57 <vimproved> it's hitting the assert in the securiry context stuff that the allowlist and the blocklist result aren't the same because for some reason on the transition from libwayland back to zig the global is getting set to an empty struct

19:06 <vimproved> suspect this is maybe an issue with an incompatibility between flatpak's libwayland and the system's

20:32 <ifreund> vimproved: oh, thats probably my fault

20:32 <ifreund> will fix tomorrow

20:49 <bwbuhse> I did *not* do all of the investigating that vimproved but I think I'm possible having the same issue? https://paste.gentoo.zip/47d9a6UU this is with a debug build of v0.3.8 from scratch but it was happening with my Gentoo ::guru build, too

21:39 <ifreund> bwbuhse: yeah that's the same thing

21:40 <ifreund> prefer 0.3.7 over 0.3.8 for now

21:40 <ifreund> will tag 0.3.9 tomorrow

21:55 <bwbuhse> yeah I just went back to 0.3.7, thanks!