ifreund changed the topic of #river to: river - a dynamic tiling wayland compositor - https://github.com/ifreund/river - channel logs: https://freenode.irclog.whitequark.org/river/
ifreund has quit [Ping timeout: 265 seconds]
ifreund has joined #river
DrewK has joined #river
DrewK has quit [Quit: Connection closed]
ifreund has quit [Ping timeout: 260 seconds]
hspak4 has joined #river
st4ll11 has joined #river
anthony25_ has joined #river
hspak has quit [*.net *.split]
anthony25 has quit [*.net *.split]
inclement has quit [*.net *.split]
st4ll1 has quit [*.net *.split]
anthony25_ is now known as anthony25
hspak4 is now known as hspak
inclement has joined #river
<leon-p> fwiw I got bored and turned that little toplevel list thingy into something proper, supporting outputs, proper human readable formating and json.
waleee-cl has quit [Quit: Connection closed for inactivity]
ifreund has joined #river
gspe has joined #river
yyp has joined #river
gspe has quit [Quit: gspe]
yyp has quit [Quit: disconnected]
<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
anthony25 has quit [Quit: Quitte]
anthony25 has joined #river
<travankor> novakane[m]: doesn't waybar have something similar
<novakane[m]> travankor: I don't use waybar so I can't tell
<travankor> yambar?
<novakane[m]> yep
<travankor> should be possible to implement something similar
<daurnimator> ifreund: do you follow master zig or keep to releases?
<daurnimator> ifreund: and follow up question: do you intend to do a release after zig 0.8.0?
<ifreund> daurnimator: a release is blocked the massively breaking changes that are nearly finished in the river-layout PR
<ifreund> and river tracks zig releases, though this just started to cause issues with the glibc 2.33 release as it creeps into distros :/
<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
<ifreund> as for the linking issues with libxkbcommon, that's because you're on arch which just updated to glibc 2.33
<ifreund> a workaround as described in my last comment here should be possible: https://github.com/ifreund/river/issues/232
<ifreund> really though I need to either fix this issue upstream or bug andrew about it before 0.8.0
<ifreund> we thought we had it fixed for 0.7.0 but we forgot about linking it seems :/
gspe has joined #river
trav29708 has joined #river
trav29708 has quit [Remote host closed the connection]
<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
<ifreund> leon-p: run zig libc for an example
<leon-p> thanks, that works. I can build river again
<ifreund> nice!
<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
<ifreund> didn't I fix that on master?
<leon-p> just grepping the source I think not. What you did was send outputEnter on view map.
<ifreund> wlroots should then send output enter when new handles are created once we set it for the wlroots object
<leon-p> it does not for me
<ifreund> leon-p: if you're running the river-layout branch it doesn't yet have the commit fixing it I think
<ifreund> scratch that, it does
<leon-p> small problem: river creates outputs _before_ it executes the startup command
<leon-p> (don't know if github likes / supports PRs against PRs)
<leon-p> other than that one issue it should probably work
<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
waleee-cl has joined #river
ifreund has quit [Quit: WeeChat 3.0.1]
gspe has quit [Quit: gspe]
gspe has joined #river
ifreund has joined #river
ericpraline has joined #river
<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.
<ifreund> that's intentional, though I can't say i spent all that much time thinking about it
<ericpraline> ok, thanks
<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
<ericpraline> exceedingly uncommon not to clear the input.
<ifreund> Feel free to open a PR if you like
<ifreund> waylock will be rewritten/replaced as soon as I or someone else get around to writing/implementing a proper screenlocker protocol
<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.
<ifreund> hmm, don't think I've ever seen that, is this with river or another project?
<leon-p> river
<leon-p> I'll save the error trace next time it happens
<leon-p> ifreund: it happened again: https://paste.rs/H9h
<ifreund> I hate these noise error return traces, I should try and fix them sometime
<ifreund> it's faling because openat() fails with ENOENT whent the scanner tries to open one of the xml files
<leon-p> it is environment dependant
<leon-p> bloody hell
<ifreund> you have wayland-protocols and pkg-config installed?
<leon-p> definitely
<leon-p> ok, right now I have two terms open, in one it works, in the other not
<ifreund> ok, don't close the broken one :D
<leon-p> I think I can reproduce it
<leon-p> the good one is a fresh terminal
<leon-p> the broken one is spawned through alacrittys "spawn a new instance" feature
<leon-p> but that's not it.
<leon-p> if in the broken one i `cd .` it works again
<leon-p> or not
<ifreund> to log the filename: https://0x0.st/-Z8l.diff
<leon-p> error.FileNotFound, file: protocol/river-control-unstable-v1.xml
<leon-p> and that is definitely there
<ifreund> I guess your cwd is not the root of the repo then somehow
<leon-p> if I open fresh terminals it works, so I'll just keep on doing that
<ifreund> weird
<ifreund> changing zig-wayland to use the build root insted of the cwd might fix this
<ifreund> and would arguably be more correct
<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
<leon-p> now onto the real problem: How to get river to execute the init before spawning outputs but after starting the server
<ifreund> that would require running it before creating the wlroots backend, which is probably not feasible
<ifreund> we kinda need the backend to initialize the rest of river's interfaces
<leon-p> that is problematic, because that way we default output options won't work for outputs present at server start
<leon-p> you know, we could also just cheat and have rivertile set all options :P
<ifreund> leon-p: pushed a zig-wayland commit that might fix your issue
<leon-p> thanks
<ifreund> Not really a fan of giving rivertile special responsibilities
ericpraline has quit [Quit: Connection closed]
<leon-p> broken term is still broken, but at least the error message is now readable :D
<ifreund> hmm, the error message changed?
<leon-p> Could not open input file: No such file or directory
<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.
<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.
<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
<leon-p> yeah, take your time.
<leon-p> My back-up solution is "riverctl declare-option-for-all-outputs", I'll investigate it in the meantime
<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
<ifreund> hmm, that also feels like a workaround :/
<leon-p> indeed it does. It is output defaults, but the other way around. Declare options _after_ outputs were created
<leon-p> would require the user to re-run the command on output layout change, but kanshi support exec'ing commands
<edrex> leon-p pr on pr should work fine, but there's no special UI for linking them or anything like that.
<edrex> (since a merged pr updates the target branch, the changes will show up in the upstream pr then)
<leon-p> edrex: thanks.
<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
<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
<leon-p> yeah, I found out via that one website
<edrex> handy, that one, and not as widely known as it should be :D
<edrex> kk
<edrex> i have been deferring trying river again while I transplant myself arch -> nixos and port my editor stuff to doom-emacs :D
<edrex> seems like there will be some new stuff to test out
<leon-p> yes, layouts get ravamped
<leon-p> but we have to figure out how to have default options for outputs first
<edrex> it looks like per-output layout state is a feature in the new branch?
<leon-p> outputs always had independant layouts
<edrex> oh i am confused, I was thinking of tags
<edrex> it would be nice if tags remembered their layouts
<leon-p> impossible
<leon-p> tags are basically u32, a 32-bit unsinged integer bitfield
<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
<leon-p> remembering the layout for each tag state is therefore not feasable
<leon-p> what you can do however is have a layout that changes based on the tag state
<leon-p> that is basically what is new in that branch: layouts are not daemons instead of one-shot programs
<leon-p> so they can have all kinds of fancy featreus
<leon-p> as long as the programmer is creative enough :D
<edrex> oh, ok. have you thought about making a library of layout combinators? conditional etc
<edrex> also mirroring/rotation could maybe implemented generically with combinators
<edrex> i think that's how it was in xmonad (but it has been a long time)
<leon-p> ¯\_(ツ)_/¯ We're not that far yet
<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
<leon-p> s/moew/more
<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
<edrex> a mirror combinator could work like: `mirror someotherlayout`, and transform the data going both ways
<edrex> not sure how that would work with wayland protos though, i was thinking in terms of pipes
<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
<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
<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
<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?
<leon-p> yeah, that would be more involved
<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
<leon-p> although that way you loose basically all advantages of having layouts generated by a central daemon instead of one-shot processes.
gspe has quit [Quit: gspe]