07:06wlb: wayland-protocols Issue #140 closed \o/ (xdg-shell: allow clients to indicate if a toplevel is a dialog to avoid tiling https://gitlab.freedesktop.org/wayland/wayland-protocols/-/issues/140)
12:07wlb: weston Issue #1005 opened by Antonin Kral (bobek) Nerves kiosk + RPi5 resulting in only small cutout out being visible https://gitlab.freedesktop.org/wayland/weston/-/issues/1005
14:08vyivel: if someone wants to close an issue and make a number go down there's https://gitlab.freedesktop.org/wayland/wayland-protocols/-/issues/233
14:09kennylevinsen: we risk it being opened again later if stuff happens during the remainder of the maintenance window
14:10kennylevinsen:did it anyway
14:10wlb: wayland-protocols Issue #233 closed \o/ (wlr-layer-shell: detect occluded/suspended surface? https://gitlab.freedesktop.org/wayland/wayland-protocols/-/issues/233)
18:07riteo: folks I did it
18:07riteo: I finally multiplexed two clients in the same toplevel
18:08riteo: it works!
18:09riteo: there's still work to do but I have finally hard proof that it's viable
18:38riteo: The reason I pushed so much for this stuff is that it offloads /so much stuff/ to the compositor: input, compositing, scene-tree and it allows even to have popups outside of the window with the right tweaks.
18:40riteo: Now I "just" have to polish it, clean up all the hacky code and actually, like, finish it. I genuinely think that this approach might be useful for other clients so I'll at least try to document it once I have something I'm happy with
18:40mclasen: whats wrong with the popups outside the window that we have now ?
18:41riteo: sorry mclasen this is a continuation of an old discussion. The original discussion relates to how to embed a wayland client into another
18:41riteo: the "canonical" solution is to implement a full-fledged server with e.g. wlroots but I greatly disliked that and I think that would've forced me to have a huge buffer instead of native sub-surfaces
18:42mclasen: oh, this is xembed
18:42riteo: I think so yeah never used that API
18:43riteo: but like what I did was basically to make a huge packet snooper that runs two or more clients toghether and changes packets wherever needed to achieve this exact thing I wanted
18:43riteo: so I make a thread with this awesome abomination, run the main client through it and then whatever wants to get embedded runs through a special socket
18:44riteo: The only reason all of this works is because we're doing wayland->wayland so I can forward 99% of packets with minimal modifications (mainly the ID)
18:45riteo: and well, I just got confirmation that this works! As I said I get a lot of stuff basically for free although I need to fix/emulate a few things like keyboard focus and the like.
18:45riteo: Also this makes maintenance a breeze as I can hook up a whole interface in very little time, as it piggy-backs the generated headers for information about signatures and whatnot
18:45vyivel: i presume this kind of proxy would need to know all interfaces used in order to keep track of id allocation, right?
18:45riteo: yea exactly
18:46riteo: but no biggie in my case. I just put the interface in a big list and I'm done with it right now. I'm aware that it's not exactly efficient (could probably use an hashmap or something) but I'm still in the hacking phase (although basically the end of it I think)
18:46vyivel: do you filter out unknown globals?
18:46riteo: I think so yea
18:46riteo: I also filter some annoying ones to embedded clients for now
18:47riteo: it was also surprisingly "simple" to implement, definitely compared to a whole compositor. "Just" ~1300 LoC for the C++ implementation file
18:48orowith2os[m]: riteo: sounds neat. I think there's a GTK project out there that might be able to make use of it
18:48riteo: oh that's interesting
18:49riteo: I'd like to turn it into a library eventually but I'm not sure whether that'd be really that easy, as this code is embedded into godot
18:49riteo: the temptation to use their std lib was too high to not do that
18:49riteo: it's still very C-y though and I think most of the effort I spent was actually figuring out what I really wanted though
18:50riteo: I'll definitely try tro document at least the various approaches used and the various concepts needed to implement it
18:51riteo: uh also this does _not_ depend on wayland-server. It manipulates the raw bytes, with all the pain that entails
18:51orowith2os[m]: riteo: check out https://gitlab.gnome.org/jpu/cambalache
18:51orowith2os[m]: they use an embedded wlroots compositor to support multiple GTK versions
18:51riteo: oh I see
18:51riteo: that's like, exactly the usecase this stuff has probably
18:52riteo: what I mean is that the whole reason I'm working on this is that godot needs a way to preview running games
18:52riteo: and I guess this needs a very similar thing
18:52orowith2os[m]: can you split out everything you have into a separate repo (I don't care about it relying on godot std) so I can take a peek?
18:52riteo: rn it's very awful and still kinda broken so I don't feel like it sorry
18:52orowith2os[m]: fair. I just want to get a feel for what it's like
18:53riteo: It's bad :P
18:53riteo: jokes aside yea, sorry, gotta have a little bit more patience but I swear I'll share it one way or the another soon™
18:53riteo: I have a pic though if you want to see it
18:53riteo: with the running client
18:54orowith2os[m]: it's funny how much cursed stuff you can do with wl. Just early I mentioned in the gnome-shell matrix the possibility of a wayland proxy that just implements some protocols on top of mutter dbus apis...
18:55riteo: yea this protocol is full of hacking possibilities
18:55riteo: the surface-centric approach really payed out
18:55riteo: paid*
18:56orowith2os[m]: Wayland shenanigans might actually be what gets me to write C/++, I'm not too confident on me being able to write it in Rust without it being hellish
18:56orowith2os[m]: might hack on content-type for mutter later, who knows...
18:57riteo: I think it might be worth it _exactly_ because of the memory shenanigans
18:57riteo: at least while you figure out what the problem actually is, just like I did rn :P
19:30orowith2os[m]: riteo: oh, the problem is mainly just Rust's safety guarantees. If I said "screw it" and went to raw pointers, I should be okay, but I don't want to.
19:30riteo: oh I see
19:31riteo: I don't know much of rust sorry for my ignorance
19:31riteo: still I can imagine why that would be annoying to use
19:33orowith2os[m]: one day I'll figure it out. DIsplay servers are just complicated. I've been wanting to write a Wayland compositor on top of X11 for a while, but I'm not sure if I want to bite the bullet with C or Rust.
19:33orowith2os[m]: Never am.
19:34orowith2os[m]: Might end up using some cursed "C with classes" thing, with std::expected and std::optional on top of it
19:35vyivel: "Wayland compositor on top of X11" a wayland server that acts as an x11 client?
19:36orowith2os[m]: a "reverse-xwayland", if you will. I've thrown the idea around a lot, without any action
19:36orowith2os[m]: wayland clients get to run on top of X11 seamlessly without needing to implement an X11 backend themselves
19:36vyivel: what's the purpose of it?
19:38orowith2os[m]: I'd like to see if it would put some of the "but then modern software won't support my archaic x11 window manager setup if they remove x11 support!!1111!!!" complaints to rest
19:38orowith2os[m]: since i know GTK5 is intending to do away with the X11 backend, whenever that comes to be
19:40orowith2os[m]: also bringing Wayland to those old BSDs that can't or won't support Wayland, for whatever reason
19:47riteo: wait didn't waylandx already exist or was it just the name for an hypothetical thing
19:49kennylevinsen: we have mentioned it many types as a hypothetical
19:50orowith2os[m]: pac85 forked smithay at some point and got something going, I think
19:50orowith2os[m]: plus a (not sure if finished) C impl
19:50orowith2os[m]: https://gitlab.com/pac85/smithay-waylandx
19:51orowith2os[m]: I didn't feel like forking and updating the smithay stuff, because it's too far disconnected from modern smithay
19:51orowith2os[m]: oh, and here's the C impl: https://gitlab.com/pac85/waylandx
22:41wlb: weston Merge request !1704 opened by Leandro Ribeiro (leandrohrb) weston-image: get H.273 CICP colorimetry data from PNG and make use of that https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1704 [Clients], [Colour management]