09:32 <xaltsc> Hey I

09:33 <plumeus> I just got reminded of "Hey You Pikachu" from this.

09:34 <xaltsc> Hey I'm using EWW with ristate (through this little script https://paste.sr.ht/~xaltsc/55e1b2f2a215c40b662b1949ba31aa7396c1d091). For some reason, it seems to crash river (0.2.4, void package). The only hint I seem to be able to find atm is the "broken pipe" message on the TTY once it has crashed.

09:34 <xaltsc> Not in the TTY, in the logs for EWW

11:46 <leon-p> xaltsc: can you provide a river log? `river -log-level debug`. Might help to build river in debug mode as well for a proper stack trace

17:00 <xaltsc> leon-p: There's some other stuff in it, but here's what I had https://paste.sr.ht/~xaltsc/145bf4101b464cb1f8e004b593c0ea0a2e97fbc3

17:46 <leon-p> seems to be layout related, but without a debug build of river, there is no trace

17:50 <tiosgz> technically you could `grep -nriF '@intCast(u'` to find out one possibility that the usable box has negative size (if that can happen at all), but eh

18:27 <xaltsc> leon-p: layout related ? It happened when I was changing the active tag on an other monitor, while eww (who apparently couldn't read the values from my script).

18:28 <xaltsc> Sadly, I've fixed the problem on eww's side now and I didn't keep my old config file..

19:28 <scorpion2185[m]> I am curious about the decision to don't let windows over the screen borders, to avoid unreachable points?

19:31 <leon-p> scorpion2185[m]: I was the one who made that decission originally, here is why:

19:31 <leon-p> I implemented moving windows via the pointer

19:31 <leon-p> back then we did not have the scene graph

19:32 <leon-p> meaning, if you dragged a window to a border of a screen, while a second screen was "on the other side" of that border, we would need a lot of extra code to show the window on both

19:33 <leon-p> I did not want to write that code, but I also thought that behaviour was way to unexpected to leave in

19:33 <leon-p> so I just disallowed moving windows out of screens all-together

19:33 <leon-p> additionally, moving windows out of outputs, into "the void", always seemed very weird UX/UI to me, which was another factor

20:11 <ifreund> We'd also probably need to move windows to the stack of a different output on drag. The status quo avoids a lot of edge cases and especially with my latest interactive resize branch I think the UX is just better for a tiling first compositor/window manager