ChanServ changed the topic of #wayland to: https://wayland.freedesktop.org | Discussion about the Wayland protocol and its implementations, plus libinput
rasterman has quit [Quit: Gettin' stinky!]
user21 has joined #wayland
Company has quit [Remote host closed the connection]
feaneron has quit [Ping timeout: 480 seconds]
garnacho has quit [Ping timeout: 480 seconds]
user21 has quit [Quit: Leaving]
Company has joined #wayland
glennk has joined #wayland
Company has quit [Ping timeout: 480 seconds]
nerdopolis has quit [Ping timeout: 480 seconds]
Company has joined #wayland
Company has quit [Quit: Leaving]
Brainium has quit [Quit: Konversation terminated!]
kts has joined #wayland
kts has quit [Ping timeout: 480 seconds]
mclasen has quit [Ping timeout: 480 seconds]
tlwoerner has joined #wayland
tlwoerner_ has quit [Ping timeout: 480 seconds]
eluks has quit [Remote host closed the connection]
eluks has joined #wayland
garnacho has joined #wayland
crazybyte4 has joined #wayland
sally_ has joined #wayland
sally has quit [Ping timeout: 480 seconds]
bodiccea has joined #wayland
sewn has quit [Read error: Connection reset by peer]
sewn has joined #wayland
slimbo has joined #wayland
slim has quit [Ping timeout: 480 seconds]
aelius has quit [Remote host closed the connection]
Moprius has quit [Remote host closed the connection]
tzimmermann has quit [Quit: Leaving]
mohit815822635306 has quit [Remote host closed the connection]
mohit815822635306 has joined #wayland
leon-anavi has quit [Quit: Leaving]
kts has quit [Ping timeout: 480 seconds]
rasterman has quit [Quit: Gettin' stinky!]
<riteo>
folks I did it
<riteo>
I finally multiplexed two clients in the same toplevel
<riteo>
it works!
<riteo>
there's still work to do but I have finally hard proof that it's viable
narodnik has quit [Ping timeout: 480 seconds]
selckin has quit [Quit: selckin]
<riteo>
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.
<riteo>
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
<mclasen>
whats wrong with the popups outside the window that we have now ?
<riteo>
sorry mclasen this is a continuation of an old discussion. The original discussion relates to how to embed a wayland client into another
<riteo>
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
<mclasen>
oh, this is xembed
<riteo>
I think so yeah never used that API
<riteo>
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
<riteo>
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
<riteo>
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)
<riteo>
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.
<riteo>
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
<vyivel>
i presume this kind of proxy would need to know all interfaces used in order to keep track of id allocation, right?
<riteo>
yea exactly
<riteo>
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)
<vyivel>
do you filter out unknown globals?
<riteo>
I think so yea
<riteo>
I also filter some annoying ones to embedded clients for now
<riteo>
it was also surprisingly "simple" to implement, definitely compared to a whole compositor. "Just" ~1300 LoC for the C++ implementation file
<orowith2os[m]>
riteo: sounds neat. I think there's a GTK project out there that might be able to make use of it
<riteo>
oh that's interesting
<riteo>
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
<riteo>
the temptation to use their std lib was too high to not do that
<riteo>
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
<riteo>
I'll definitely try tro document at least the various approaches used and the various concepts needed to implement it
<riteo>
uh also this does _not_ depend on wayland-server. It manipulates the raw bytes, with all the pain that entails
<orowith2os[m]>
they use an embedded wlroots compositor to support multiple GTK versions
<riteo>
oh I see
<riteo>
that's like, exactly the usecase this stuff has probably
<riteo>
what I mean is that the whole reason I'm working on this is that godot needs a way to preview running games
<riteo>
and I guess this needs a very similar thing
<orowith2os[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?
<riteo>
rn it's very awful and still kinda broken so I don't feel like it sorry
<orowith2os[m]>
fair. I just want to get a feel for what it's like
<riteo>
It's bad :P
<riteo>
jokes aside yea, sorry, gotta have a little bit more patience but I swear I'll share it one way or the another soon™
<riteo>
I have a pic though if you want to see it
<riteo>
with the running client
<orowith2os[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...
<riteo>
yea this protocol is full of hacking possibilities
<riteo>
the surface-centric approach really payed out
<riteo>
paid*
<orowith2os[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
<orowith2os[m]>
might hack on content-type for mutter later, who knows...
<riteo>
I think it might be worth it _exactly_ because of the memory shenanigans
<riteo>
at least while you figure out what the problem actually is, just like I did rn :P
coldfeet has quit [Quit: Lost terminal]
cyrinux9 has quit []
cyrinux9 has joined #wayland
<orowith2os[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.
<riteo>
oh I see
<riteo>
I don't know much of rust sorry for my ignorance
<riteo>
still I can imagine why that would be annoying to use
<orowith2os[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.
<orowith2os[m]>
Never am.
<orowith2os[m]>
Might end up using some cursed "C with classes" thing, with std::expected and std::optional on top of it
<vyivel>
"Wayland compositor on top of X11" a wayland server that acts as an x11 client?
<orowith2os[m]>
a "reverse-xwayland", if you will. I've thrown the idea around a lot, without any action
<orowith2os[m]>
wayland clients get to run on top of X11 seamlessly without needing to implement an X11 backend themselves
<vyivel>
what's the purpose of it?
<orowith2os[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
<orowith2os[m]>
since i know GTK5 is intending to do away with the X11 backend, whenever that comes to be
<orowith2os[m]>
also bringing Wayland to those old BSDs that can't or won't support Wayland, for whatever reason
mclasen has quit [Ping timeout: 480 seconds]
<riteo>
wait didn't waylandx already exist or was it just the name for an hypothetical thing
<kennylevinsen>
we have mentioned it many types as a hypothetical
<orowith2os[m]>
pac85 forked smithay at some point and got something going, I think
<orowith2os[m]>
plus a (not sure if finished) C impl