00:07 <apoorv569> ifreund: I see.. never heard of kanshi.. it would be nice if river has everything built-in so we don't have to rely on external packages like we needed with xorg..

00:07 <apoorv569> like sway has all these things built-in

04:57 <TheAnachron> apoorv569: IMO its a strength that river focuses on doing one thing well only

09:33 <ifreund> after sleeping on it, I'm leaning towards giving the WM total control over dimensions during interactive move/resize. I'll need to implement it to make sure it's actually a good idea though

10:22 <flower_> toggle visible tag, is it possible to set how the windows of different visible tags are displayed? This probably needs the notion of a 'master' tag. Example: I work on tag 1 and I have two terminals on tag 2, if I toggle tag2 visible while working on tag 1, I want them to get displayed on the right side of the focused window of tag 1

10:23 <flower_> (tag 1 has rivertile-left as setting in that case)

15:12 <leon-p> ifreund: sorry for the late reply, was sick and without laptop

15:12 <leon-p> I generally agree with more control for WMs

15:13 <leon-p> however, the protocol is inherently limiting in quite a few ways, which makes lives of implementors easier

15:14 <leon-p> I am just worried whether we can keep rivers currently "snapiness" w.r.t. resizing and moving windows

15:15 <leon-p> whereas other wayland desktops update cursor position and window geometry independently, on river they are coupled during resize / move and that just feels infinitely better IMO

15:16 <leon-p> I really can't stand it when you move a window and it looks like it's attached to the cursor by a rubber band

15:18 <leon-p> river is basically the only wayland desktop I know off that got this right

15:18 <leon-p> s/wayland//, actually

15:20 <vyivel> …so if the window is late to reply, the cursor update rate is slowed down?

15:20 <leon-p> for resize has, for move no

15:20 <leon-p> s/has/yes/

15:21 <vyivel> well moving doesn't have to be acked anyway

15:21 <leon-p> note to decouple the concept of the cursor image and the logical pointer

15:22 <vyivel> idk if i saw my cursor movement stop corresponding to my actions i'd think my touchpad is broken

15:24 <leon-p> the actual difference is so low that in the end it just makes the windows geometry changes feel more smooth

15:24 <leon-p> try resizing and moving floating windows on river vs sway, there is a difference

15:25 <vyivel> hmm

15:26 <vyivel> i was thinking of some extreme cases where the client doesn't reply at all but that's solvable with some very small timeout

15:26 <vyivel> interesting, i should try this too

15:31 <ifreund> it's pretty much the same idea as as transaction system, delay the update by a couple frames max to make things frame perfect

15:32 <vyivel> so you store logical cursor position separately from visual?

15:32 <vyivel> with two wlr_cursors or do you implement output/region mapping manually?

15:34 <ifreund> river's master branch uses only one wlr_cursor and constrains movement to the output bounds manually

15:35 <ifreund> and doesn't support region mappings

15:35 <ifreund> the rwm branch doesn't implement this (yet)

15:35 <vyivel> i see

15:36 <ifreund> one slightly funky thing is how this interacts with e.g. foot resizing in steps of the terminal cell size, it feels a bit jerky currently

15:36 <ifreund> I think that could be smoothed out though with a minor amount of work

15:41 <ifreund> also, it can feel subjectively worse than the rubber-banding if the window is slow enough in its ack_configure/commit

15:41 <ifreund> for example mpv while playing a video

15:43 <ifreund> I guess that would be fixed with a separate timeout

15:44 <vyivel> mpv is not slow, it's broken

15:44 <ifreund> fair :D

15:45 <ifreund> It really should be able to just scale the current frame of the video and commit that right away

15:45 <vyivel> it should at the very least not resize on xdg_toplevel configure and wait for xdg_surface configure

15:46 <ifreund> leon-p: anyhow, I actually can't think of any other major limitations of the current rwm protocol draft besides interactive move/resize related stuff

15:47 <ifreund> moving the things I propose to the WM would also allow stuff like dragging a window in a tiled layout and having the rest of the layout move to make space, and then having it snap int place at the end

15:47 <ifreund> s/int/into/

15:48 <ifreund> and I think the code needed in the WM to reimplement the current move/resize logic that would be moved out shouldn't be more than 50 lines

15:48 <ifreund> if even that

15:49 <ifreund> hope you're feeling less sick and don't feel any pressure to reply quickly here :)

15:50 <ifreund> it'll be at least a couple days before I try implementing these ideas

16:07 <leon-p> I am less sick, don't worry :)

16:08 <leon-p> in fact, I am off to the cinema now, seeing that new animated cat movie with friends

16:10 <ifreund> enjoy :)

16:15 <ifreund> actually, we kinda already do the anti-rubber-band thing on the rwm branch as it's a side affect of only processing input events while there is no transaction in progress

16:18 <ifreund> I guess the cursor position gets updated early currently, but it's updated at the same rate