05:45 <leon-p> fwiw I got bored and turned that little toplevel list thingy into something proper, supporting outputs, proper human readable formating and json.

09:34 <novakane[m]> leon-p it looks really nice now, it doesn't give me the good output but I didn't configure it in river though so it probably because of that

11:19 <travankor> novakane[m]: doesn't waybar have something similar

11:23 <novakane[m]> travankor: I don't use waybar so I can't tell

11:23 <travankor> yambar?

11:32 <novakane[m]> yep

11:42 <travankor> should be possible to implement something similar

11:51 <daurnimator> ifreund: do you follow master zig or keep to releases?

11:51 <daurnimator> ifreund: and follow up question: do you intend to do a release after zig 0.8.0?

11:53 <ifreund> daurnimator: a release is blocked the massively breaking changes that are nearly finished in the river-layout PR

11:54 <ifreund> and river tracks zig releases, though this just started to cause issues with the glibc 2.33 release as it creeps into distros :/

11:56 <ifreund> leon-p: that sounds reasonable, I've got some work I need to get done first before I can take a proper look this evening though

11:57 <ifreund> as for the linking issues with libxkbcommon, that's because you're on arch which just updated to glibc 2.33

11:58 <ifreund> a workaround as described in my last comment here should be possible: https://github.com/ifreund/river/issues/232

11:58 <ifreund> really though I need to either fix this issue upstream or bug andrew about it before 0.8.0

11:59 <ifreund> we thought we had it fixed for 0.7.0 but we forgot about linking it seems :/

13:46 <leon-p> hmm... is the format of the file .setLibCFile() expects documented somewhere? It is not the typical linker script at /usr/lib/libc.so

14:11 <ifreund> leon-p: run zig libc for an example

14:40 <leon-p> thanks, that works. I can build river again

14:44 <ifreund> nice!

14:52 <leon-p> we don't send outputEnter events for foreign toplevel handles when they are created. That is breaking the protocol because we do send outputLeave for that output of the view is moved to a different one

14:53 <ifreund> didn't I fix that on master?

14:58 <leon-p> just grepping the source I think not. What you did was send outputEnter on view map.

15:00 <ifreund> wlroots should then send output enter when new handles are created once we set it for the wlroots object

15:04 <leon-p> it does not for me

15:08 <ifreund> leon-p: if you're running the river-layout branch it doesn't yet have the commit fixing it I think

15:08 <ifreund> scratch that, it does

15:32 <leon-p> small problem: river creates outputs _before_ it executes the startup command

15:37 <leon-p> anyway, my proposal is here: https://github.com/Leon-Plickat/river/tree/default-option-proposal

15:38 <leon-p> (don't know if github likes / supports PRs against PRs)

15:38 <leon-p> other than that one issue it should probably work

17:04 <leon-p> for all the options related work it would be helpful if we had a way to just print all existing options, their values and output / default status

18:58 <ericpraline> hello. i have a stupid question: when i enter a bad password in waylock, the input is not cleared, i.e. i have to delete the wrong password by pressing backspace or escape. this is certainly a feature, right? i was just wondering because i've never encountered that behavior in a password prompt.

19:04 <ifreund> that's intentional, though I can't say i spent all that much time thinking about it

19:09 <ericpraline> ok, thanks

19:18 <ericpraline> it's not a big deal ofc, but imo, the usual behaviour makes more sense. when you type a password and hit enter, you are assuming that what you typed is correct. if it is not correct, you will (i think), in the majority of cases, not know where the mistake is, which means that you are going to clear the input anyway. i also think that it's

19:18 <ericpraline> exceedingly uncommon not to clear the input.

19:24 <ifreund> Feel free to open a PR if you like

19:24 <ifreund> waylock will be rewritten/replaced as soon as I or someone else get around to writing/implementing a proper screenlocker protocol

19:34 <leon-p> I have a weird problem with zig-wayland: it randomly causes the build to fail (with std functions throwing file not found and out of memory errors), but after some time it works again. Spooky.

19:34 <ifreund> hmm, don't think I've ever seen that, is this with river or another project?

19:34 <leon-p> river

19:34 <leon-p> I'll save the error trace next time it happens

19:41 <leon-p> ifreund: it happened again: https://paste.rs/H9h

19:42 <ifreund> I hate these noise error return traces, I should try and fix them sometime

19:44 <ifreund> it's faling because openat() fails with ENOENT whent the scanner tries to open one of the xml files

19:44 <leon-p> it is environment dependant

19:44 <leon-p> bloody hell

19:44 <ifreund> you have wayland-protocols and pkg-config installed?

19:44 <leon-p> definitely

19:45 <leon-p> ok, right now I have two terms open, in one it works, in the other not

19:46 <ifreund> ok, don't close the broken one :D

19:46 <leon-p> I think I can reproduce it

19:46 <leon-p> the good one is a fresh terminal

19:46 <leon-p> the broken one is spawned through alacrittys "spawn a new instance" feature

19:47 <leon-p> but that's not it.

19:47 <leon-p> if in the broken one i `cd .` it works again

19:47 <leon-p> or not

19:47 <ifreund> to log the filename: https://0x0.st/-Z8l.diff

19:51 <leon-p> error.FileNotFound, file: protocol/river-control-unstable-v1.xml

19:51 <leon-p> and that is definitely there

19:52 <ifreund> I guess your cwd is not the root of the repo then somehow

19:53 <leon-p> if I open fresh terminals it works, so I'll just keep on doing that

19:54 <ifreund> weird

19:54 <ifreund> changing zig-wayland to use the build root insted of the cwd might fix this

19:54 <ifreund> and would arguably be more correct

19:55 <leon-p> well it is totally possible for a process to have a weird cwd if the spawning process did something weird. Might be alacritties "spawn new instance" thing

19:56 <leon-p> now onto the real problem: How to get river to execute the init before spawning outputs but after starting the server

19:57 <ifreund> that would require running it before creating the wlroots backend, which is probably not feasible

19:57 <ifreund> we kinda need the backend to initialize the rest of river's interfaces

19:59 <leon-p> that is problematic, because that way we default output options won't work for outputs present at server start

20:00 <leon-p> you know, we could also just cheat and have rivertile set all options :P

20:07 <ifreund> leon-p: pushed a zig-wayland commit that might fix your issue

20:07 <leon-p> thanks

20:08 <ifreund> Not really a fan of giving rivertile special responsibilities

20:08 <leon-p> broken term is still broken, but at least the error message is now readable :D

20:09 <ifreund> hmm, the error message changed?

20:09 <leon-p> Could not open input file: No such file or directory

20:10 <leon-p> anyway, I don't know how to approach output defaults if we can't execute init before we create outputs. We would need to retroactively modify output options, which does not seem very nice to me.

20:12 <ifreund> I'm not sure what a good solution is either. Right now I'm pretty exhausted and need to catch up on a lot of sleep though.

20:12 <ifreund> Thanks for working on this today, I'll take a good look at what you've come up with and see if I can't find a solution

20:13 <leon-p> yeah, take your time.

20:13 <leon-p> My back-up solution is "riverctl declare-option-for-all-outputs", I'll investigate it in the meantime

20:13 <ifreund> I've been running the river-layout branch for weeks? at this point and haven't had any issues aside from this major annoyance surrounding output options

20:14 <ifreund> hmm, that also feels like a workaround :/

20:14 <leon-p> indeed it does. It is output defaults, but the other way around. Declare options _after_ outputs were created

20:14 <leon-p> would require the user to re-run the command on output layout change, but kanshi support exec'ing commands

21:03 <edrex> leon-p pr on pr should work fine, but there's no special UI for linking them or anything like that.

21:04 <edrex> (since a merged pr updates the target branch, the changes will show up in the upstream pr then)

21:26 <leon-p> edrex: thanks.

21:26 <leon-p> but considering the PR branch is also from my repo, I'll keep it as is and push it if we decide that the approach is sound

21:26 <edrex> leon-p also, you may have already discovered it, but you can use git reflog to see the history of refs your working copy has had, and then reset --hard to get back a branch that was force-pushed

21:27 <leon-p> yeah, I found out via that one website

21:27 <edrex> handy, that one, and not as widely known as it should be :D

21:27 <edrex> kk

21:31 <edrex> i have been deferring trying river again while I transplant myself arch -> nixos and port my editor stuff to doom-emacs :D

21:31 <edrex> seems like there will be some new stuff to test out

21:33 <leon-p> yes, layouts get ravamped

21:33 <leon-p> but we have to figure out how to have default options for outputs first

21:34 <edrex> it looks like per-output layout state is a feature in the new branch?

21:34 <leon-p> outputs always had independant layouts

21:34 <edrex> oh i am confused, I was thinking of tags

21:34 <edrex> it would be nice if tags remembered their layouts

21:35 <leon-p> impossible

21:35 <leon-p> tags are basically u32, a 32-bit unsinged integer bitfield

21:36 <leon-p> that means river has 32 tags and the number of possible combinations is the highest number that fits into a 32-bit unsinged integer minus 1

21:36 <leon-p> remembering the layout for each tag state is therefore not feasable

21:36 <leon-p> what you can do however is have a layout that changes based on the tag state

21:36 <leon-p> that is basically what is new in that branch: layouts are not daemons instead of one-shot programs

21:37 <leon-p> so they can have all kinds of fancy featreus

21:37 <leon-p> as long as the programmer is creative enough :D

21:37 <edrex> oh, ok. have you thought about making a library of layout combinators? conditional etc

21:37 <edrex> also mirroring/rotation could maybe implemented generically with combinators

21:38 <edrex> i think that's how it was in xmonad (but it has been a long time)

21:38 <leon-p> ¯\_(ツ)_/¯ We're not that far yet

21:39 <leon-p> however we have a pretty good idea of what a layout is supposed to do: based on some parameters generate position and dimensions for windows. nothing moew

21:39 <leon-p> s/moew/more

21:40 <leon-p> keep in mind that stuff like xmonad and awesome are really not comparable to river, because those are basically WM and widgets libraries with a runtime. River however is a complete, atomic thing

21:41 <edrex> a mirror combinator could work like: `mirror someotherlayout`, and transform the data going both ways

21:42 <edrex> not sure how that would work with wayland protos though, i was thinking in terms of pipes

21:43 <leon-p> I am not sure I follow completely. But with the new approach you can certainly have a layout generator that has one outputs layout depending on a nother one

21:44 <leon-p> as long as the end-result is nothing more than a set of x,y coords plus width,height values for all windows (on one or multiple outputs), you can do it

21:45 <leon-p> and you can depend on an arbitrary amount of live changable values, or basically anything you can think of. you could have a layout that changes based on the time if you wanted to. just keep in mind that in the end the windows are still in a list so complex layouts don't really server a purpose

21:45 <edrex> with pipes one layout could just spawn another and transform the data streams going both ways. seems like it would be more involved to make a layout combinator that speaks wayland protos, since it would have to pretend to be a proto server for the subproc, right?

21:46 <leon-p> yeah, that would be more involved

21:46 <leon-p> if you wanted to use that approach, my advise would be a layout daemon that reads the layout from a thrid process via a pipe

21:48 <leon-p> although that way you loose basically all advantages of having layouts generated by a central daemon instead of one-shot processes.