08:44 <leon-p> at first I thought the new updating sequence of the WM protocol would make window management logic in scheme kinda ugly, but I find that it actually works quite well

08:44 <leon-p> all I have to do is create lists "scheduled-<operation>" and add additional hook procedures to the start-*-phase-hook

10:39 <leon-p> ifreund: when setting an input region on a decoration surface, is that in buffer coords (unscaled) or surface coords (scaled)?

10:46 <leon-p> huh, buffer apparently...

11:12 <ifreund> leon-p: uh, wayland.xml says "The input region is specified in surface-local coordinates."

11:12 <ifreund> glad to hear that the update sequence stuff is working out well in scheme

11:13 <ifreund> I think it should be possible to implement the window management logic as two pure functions now

11:15 <ifreund> windowing_update(wm state, events from server) -> (wm state, window management state requests)

11:15 <ifreund> and the same kind of thing for the rendering update

11:21 <Franciman> leon-p: do ytou have your scheme code somewhere?

11:53 <Vitis> I was wondering if anyone else ran into an issue of mouse cursor twitching back and forth during movement with a fullscreen game. Game is running from steam through proton(i tried proton 9, experimental, hotfix) natively on wayland and it's present in all games regardless of proton version. I tried the same case under Sway but everything works

11:53 <Vitis> normally which points into it probably being a mouse cursor constraint bug. I'm using river 0.3.7-1 from the archlinux repos. Newer releases don't build on arch so I can't test if newer version has fixed this.

12:09 <leon-p> Franciman: yes, but not on my usual source. the network at my institute blocks all git except their own for whatever reason, so I used that for now. Let me find out if I can set it too public

12:10 <leon-p> ifreund: when I set input region in surface coordinates, it did not work. Although I do wonder if maybe the viewporter input region path is buggy in wlroots?

12:10 <leon-p> anyway, I now have proper motif-esque borders: https://files.mastodon.social/media_attachments/files/114/341/897/056/092/122/original/9ab3d79f29e7c85f.png

12:12 <leon-p> Franciman: can you access this? https://gitlab.gwdg.de/leonhenrik.plickat/antares

12:12 <Franciman> i can \o/

12:14 <leon-p> ifreund: I am interested in the pure function approach, however I decided to use just hooks since they seem to work quite for emacs w.r.t. allowing users to extend the logic. Sometimes doing it imperative can be more straight-forward than doing it functional

12:15 <leon-p> Franciman: note that it's not quite yet on the same level as the previous C implementation: There are no widgets yet and I haven't ported all the window management logic (Scheme) that the old one had

12:22 <ifreund> leon-p: I think there might indeed be a bug in wlr_scene

12:23 <ifreund> https://gitlab.freedesktop.org/wlroots/wlroots/-/blob/master/types/scene/surface.c#L222

12:23 <ifreund> this function accepts buffer coords but then uses them as surface coords

12:24 <leon-p> I guess input region isn't commonly used, so something like that may slip

12:24 <ifreund> I think it's more that it isn't commonly used in combination with viewporter :D

12:25 <leon-p> fair, tbh :)

12:29 <ifreund> leon-p: nevermind, that wlroots function is fine, I was being dumb

12:29 <ifreund> not sure if there's a bug or not, would need a minimal reproducer I guess

12:31 <leon-p> at the least the offset seems to be in buffer coords. I have a texture and then use viewporter to map parts of it to surface. If I map a part of the texture that is _not_ at (0,0) to a surface, than surface regions would start at (0,0) while buffer regions would start at the (x,y) of the texture part I view-ported, no?

12:32 <leon-p> I don't think I have any xdg-shell thing lying around for a minimal reproducer though :/

12:32 <leon-p> at least nothing that still builds

12:33 <Vitis> Also there's another thing i found and that's with mouse configuration if i set flat accel profile and acceleration to 1 the mouse speed in river is exactly twice of what it is with the same setting under sway. Under sway if i set profile flat and acceleration to 0 in order to get the same sensitivity i need to set acceleration to -0.5 in river.

12:34 <leon-p> Vitis: river does nothing magic with any of those values, we pass them straight along to libinput. Maybe sway does something different here?

12:39 <ifreund> leon-p: yes, if you use viewporter to set the source box to something with non-zero x/y that should have no affect on the coordinate space used for input regions

12:40 <ifreund> note that the source box coordinates are post-transform/scale

12:43 <leon-p> yeah, anything else would not make much sense

13:41 <elagost> I'm using a 'scratchpad' tag (as defined here https://wiki.archlinux.org/title/River#Scratchpads ) - is there a way to focus on the window that is on the tag when it comes up?

20:39 <Guest80> heyhey, so is there a way to disable scaling for xwayland for a specific program, or just in general? i cant find anything about it anywhere for river