<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