02:44 <NickH> Since we are talking about packaging, I'll add that I've now updated the unofficial deb for bookworm to 0.3.0

02:45 <NickH> See https://www.ne.jp/asahi/nickh/debian/

04:52 <LarstiQ> NickH: cheers!

04:56 <LarstiQ> ifreund: did you write that river-window-management-v1.xml by hand or is there some source from which this is produced?

05:01 <LarstiQ> ifreund: the output events say that logical outputs should not overlap, but it's at least somewhat common to overlap with output mirroring and possible but weirder with slight overlap right now. Is that an intentional restriction?

05:16 <LarstiQ> "The width/height must be greater than or equal to zero" is that ratio must be non-negative, or both of width and height?

07:57 <NickH> LarstiQ: I also periodcally make packages from the HEAD of master for my own use. I could publish them too if there is interest.

07:58 <LarstiQ> my current Debian machines are headless but I appreciate the option

08:34 <ifreund> LarstiQ: by hand

08:34 <ifreund> in the case of output mirroring, I intent to model that as a single logical output rendered to two separate physical outputs (represented by two separate wl_outputs)

08:35 <ifreund> s/intent/intend/

08:35 <ifreund> both width and height, I should change that wording though as it seems to have been unclear

09:05 <ifreund> push a commit disambiguating that stuff

09:06 <ifreund> *pushed, can't type today for some reason

10:13 <LarstiQ> ifreund: check. And the other way around, multiple logical outputs to a single physical one?

10:14 <ifreund> In theory this protocol already supports that. I don't have any plans to make that configuration possible though

10:15 <ifreund> currently, my plan is to continue to use wlr-output-management for output configuration

10:28 <novakane> what's the plan for the river layout protocol after that, is it still gonna be supported for some time?

10:31 <ifreund> novakane: I have some vague plans to make a river-compat window manager that exposes the current protocols

10:32 <ifreund> all of river-status, river-control, and river-layout will be removed from the river binary when I implement the window management protocol

10:33 <ifreund> river-compat could have it's own wayland socket it exposes to a river-layout-v3 layout generator for example, RIVER_COMPAT_DISPLAY

10:34 <ifreund> I don't know details, I'll put more thought into how to make the upgrade smooth after it's more clear what river will look like with the window management protocol implemented

10:34 <novakane> yeah, could works, ideally all clients would not be broken on the first release with rwm

10:35 <novakane> that would be pretty messy to not have at least one release cycle without a warning for that imo

10:41 <robertgzr> hello o/ does anybody else experience blurryness when going fullscreen

10:41 <robertgzr> seems to only happen with firefox from my brief testing

10:45 <robertgzr> i think it's also not properly relayouting the page

11:17 <ifreund> robertgzr: I haven't seen that before. What output configuration are you using? In particular, what scale factor?

11:49 <robertgzr> ifreund: scale factor 1.5

11:50 <robertgzr> might be a FF bug? since this doesn't happen with any other client

11:58 <novakane> robertgzr: are you sure you're not running Firefox under xwayland? iirc fractional scaling is buggy

12:00 <robertgzr> https://0x0.st/XHeB.mp4

12:00 <robertgzr> here's a clip showing this

12:01 <robertgzr> novakane: this host doesn't have X at all :)

15:31 <leon-p> just read the WM protocol and it seems pretty nice. I think this already covers the vast majority of the windowing related items in my wishlist

15:32 <leon-p> just wondering about the render_node based approach instead of setting x,y on the river_window object and having a simple numerical z odering

15:32 <leon-p> also wondering how render-node x,y interacts with river_decoration's offset

15:33 <leon-p> ah, by not allowing you to get a render-node for river-deco surfaces

15:35 <leon-p> for the get_decoration request, an edge of "none" should probably be a protocol error

15:36 <leon-p> I wonder if it should be possible to additionally create an "overlay" river-decoration surface. Use-cases would be tag display like in hikari, or showing the window dimensions during interactive resize like some X WMs do

15:37 <leon-p> and if I have a left deco surface and a top deco surface, which of those covers the top-left corner? both?

15:38 <ifreund> leon-p: actually, deco surfaces aren't supposed to have an edge any more, that was part of an earlier design I scrapped

15:38 <leon-p> speaking of, I wonder if the corners should be separate surfaces. F.e. if I wanted to render some skeumorphic borders, I'd want to have fancy corners, but use viewporter for the edges so I could use small buffers and don't need to render all the time

15:38 <leon-p> ah, I see

15:38 <leon-p> nice

15:39 <ifreund> they are always positioned relative to the top left corner, the wm knows the dimensions of the window so it can place the decorations where it likes

15:39 <leon-p> yeah that makes more sense, I like it

15:39 <ifreund> and yeah, I'm trying to go straight for the most technically difficult parts and get those solidified first

15:40 <leon-p> I think a simple WM could even get away with rendering a border buffer only once and use it for all windows with viewporter

15:40 <leon-p> good plan, I am liking what I am seeing already :]

15:40 <leon-p> although I suppose we'll also need a dedicated input config protocol now

15:40 <ifreund> there is a separate request to set borders rendered by the compositor to simplify that use-case

15:41 <leon-p> my use of "simple" here still included old-school skeumorphic borders

15:41 <ifreund> indeed we will, if you want to draft up river-input-management have at it, it should be entirely orthangonal to window-management

15:41 <leon-p> sure, will have a go

15:41 <ifreund> just like wlr-output-managent is

15:41 <leon-p> I just probably won't have the time to upstream anything to wlr-protocols

15:41 <leon-p> (and patience)

15:42 <ifreund> yeah, I don't think trying to upstream an input-config protocol is worth it yet

15:42 <ifreund> if there is interest from other compositors we can do that in the future

15:42 <leon-p> aye

15:42 <leon-p> anyway, off to karaoke now, have a good one o7

15:42 <ifreund> cheers o7

15:45 <ifreund> as for why not numerical z ordering, I think this is simpler than z ordering but have never tried to use numerical z ordering for window management before

15:46 <ifreund> don't you run into issues where you have to update the z-index of many windows just to change the relative positioning of 2 windows?

15:47 <ifreund> e.g. say you have window A with z 0, B with z 1, and C with z 2. Then you want to insert D between A and B. You now need to increment the z index of both B and C

15:48 <ifreund> It seems to me that it would generate a lot more protocol traffic than place_above/place_below but I could be convinced otherwise

16:03 <leon-p> IIRC X has numerical z ordering, but also place_above/below requests and also an additional request where you can provide an array of window IDs to make their stacking order match their order in the array

16:04 <leon-p> I think you're right though, numerical isn't that great, it could also lead to conflicts which would prob. be undefined behaviour in the protocol

16:05 <leon-p> it also has move-to-the-top and move-to-the-bottom requests