21:23 <questionable_ole> Hi there... At the risk of sounding ignorant - from what I could see river had scrapped transparency until it's more stable/mature sometime in last few years. How would you say the progress since has been - are we any closer to getting that back on?

21:33 <novakane> just guessing but I don't think so, that's probably still far in the todo list

21:46 <leon-p> questionable_ole: we only removed server-side opacity levels. if a client renders a buffer with an alpha channel, it will still appear transparent. If all you want is something simple, like say a semi-transparent terminal window, it will work.

21:50 <leon-p> (except for full-screened windows though, as that would violate the xdg-shell protocol)

21:53 <questionable_ole> leon-p: thank you - foot works perfectly like that. And just checked it in fullscreen, sure enough no opacity. Didn't even notice before. I suppose it's just digging in the client's congurations to see if some other transparency. Thinking about some RDP client and some browser. Currently on remmina and opera. Thanks for the hint

21:53 <questionable_ole> if some offer* opacity

21:56 <leon-p> as for when / if server-side opacity will return: we plan to move more windowing logic out of the server into the layout generator. I could see it also being in charge of eye-candy. Not sure how that would work yet though. And we haven't even started protocol design. So don't expect anything like that to come in the near future.

21:57 <leon-p> also note that the focus will always be on core functionality over anything else, so it's not a given that this - or any eye candy for that matter - will make its way into river at all

22:00 <questionable_ole> makes sense. While we're on the layout generators - I'm just learning my way around WMs and wayland recently, so probably not aware about many things. Is there a way to have different default layout per different output/monitor? would that be on a layout generator to support such bindings?

22:08 <leon-p> questionable_ole: different layout per output is possible. you can either use a different generator for each output or use one that supports that feature internally. mine does (stacktile), but it's not documented right now unfortunately

22:12 <questionable_ole> leon-p: funny you should mention that, I've just finished reading that big comment in main source file you wrote to yourself. What would help is seeing an example config to use with the stacktile

22:13 <leon-p> here is mine: https://paste.rs/0nD

22:14 <questionable_ole> leon-p: legend. much obliged, I'll try to tinker with something based on this

22:15 <questionable_ole> does [output:XXX] support both specific name and generic, like HDMI-A-1 ?

22:15 <leon-p> that was my intention, can't remember if I actually implemented it

22:16 <questionable_ole> I'll let you know when I get to this ;D

22:32 <questionable_ole> leon-p: I managed to build the executable (had to look up how to use zig). One thing - deps/zig-wayland in your repo is empty, so I needed to clone that from ifreund/zig-wayland's github (was a guess that turned out to work out)

22:40 <leon-p> it uses git submodules for static dependencies, so you could've just run `git submodule update --init`

22:43 <questionable_ole> I knew I was missing something, thank you

22:44 <leon-p> probably should put that in the readme. I'll do that when I get around to writing documentation

22:57 <questionable_ole> leon-p: the config file you shared - where should it reside, in the same directory as the stacktile binary? and what should the name be

22:57 <leon-p> $XDG_CONFIG_HOME/stacktile/config.ini

23:25 <questionable_ole> leon-p: getting these errors on launch (reading from config OK) https://paste.rs/7dO

23:25 <questionable_ole> river -version gives 0.1.3

23:26 <leon-p> oh yeah, forgot. we had some changes in the layout protocol after 0.1.3

23:26 <leon-p> stacktile is currently developed against river master.

23:26 <leon-p> anyway, I am off for today, it's getting late on my end

23:27 <questionable_ole> appreciate the help today, have a good one. I'll try building from master

23:30 <ifreund> river now builds with the zig self hosted compiler if you enable xwayland on this branch: https://github.com/riverwm/river/tree/next-zig

23:32 <ifreund> disabling xwayland fails to build though cause of some finickiness with conditional compilation/the way river uses it

23:32 <questionable_ole> looking at the readme it's the -Dxwayland option to the build command?

23:33 <ifreund> yes

23:33 <questionable_ole> thank you, will try it out

23:33 <ifreund> No reason to really, there's no real upside over master branch if you're an end user

23:35 <questionable_ole> as far as linux goes I'm definitely just an end user