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/
snakedye has joined #river
snakedye has quit [Client Quit]
hspak has quit [Ping timeout: 240 seconds]
travankor has joined #river
travankor has quit [Ping timeout: 240 seconds]
<leon-p> Just finished up rivertile: Provides layouts for all four main area positions and supports optional view padding.
<leon-p> maybe in the future we can give it more advanced options, like sways 'smart-gaps', but for now I think we should keep it simple
<leon-p> river itself still has a few quirks, but kinda works already if you are careful
waleee-cl has quit [Quit: Connection closed for inactivity]
travankor has joined #river
<leon-p> huh, I encountered a few crashes and suspect not all of them come from my code
<leon-p> One is definitely related to touchpad input when used with the wayland backend
<leon-p> another was an integer overflow
<leon-p> anyway, if someone wants to try out the river-layout stuff, it more or less works now. A few things left to fix, so it is not exactly "production ready", but its fine for toying around a bit.
leon-p has quit [Quit: leaving]
<ifreund> \o/
travankor has quit [Remote host closed the connection]
leon-p has joined #river
waleee-cl has joined #river
<leon-p> ifreund: do you thing rivertile should have a full layout?
<leon-p> asking since the full layout is now no longer built-in
<ifreund> leon-p: nah, I don't think its useful
<leon-p> sure
<ifreund> Hopefully my comment on the server implementation were clear enough, I'll give your new rivertile a look soon
<leon-p> they were. I was just initially a bit confused by the destroyHandler thing, until I noticed that setHandler is used for /both/ destroy and request handler :D
<leon-p> almost done implementing your comments. Using the destroy handler actually fixes a few bugs
<leon-p> most obvious bug still left is the transaction, which still acts a bit funky
<leon-p> and I get a crash on exit, but I am not sure that comes from my changes. Have to check master...
<ifreund> Yeah I haven't had a chance to try running it yet... it's getting very close though!
<leon-p> ifreund: implemented all your comments
<leon-p> I think the only thing still missing is getting transactions right
<leon-p> oh. Moving to an ArrayList means I had to use pop() instead of popFirst(). And iterate over the view stack .reverse instead of .forward, but somehow that makes things funky
<ifreund> leon-p: can't you just index into the arraylist and free the whole thing at the end?
<leon-p> probably. forgot array lists support accessing elements at a specificc index
<ifreund> could probably just use a slice come to think of it as the total size is known in advance
<ifreund> though the ArrayList may be more ergonomic
<leon-p> ok, using the index works.
<ifreund> nice, I'll give it another pass
<leon-p> heh, it's actually pretty useable as a floating WM now
<ifreund> Really wish github showed the difference between force-pushes like gitlab does :/
<ifreund> hmm, do we really want to make every layout client re-implement view padding and outer padding?
<ifreund> if they want to do something fancier with gaps they could always set them both to 0 first
<leon-p> TBF I prefer it without view padding in river.
<leon-p> view padding maybe
<leon-p> but outer padding is so specific it belongs into the layout IMO
<leon-p> and restarting layouts to change these values is trivial
<leon-p> despite, rivers approach to view padding was a bit naïve anyway.
<leon-p> I actually think even having the main view related hints in the protocol / in river a bit of a stretch. Only because you'd want to set them live should they be in there.
<leon-p> as for padding: if you want to set them live, you should write a layout that does that for you