16:25 Arsen: is there a way to embed windows within other windows? the idea I had was to do something like cage but render into an existing surface
17:13 kennylevinsen: Arsen: you can have a compositor that renders to a window (cage already supports running like that through wlroots' Wayland backend), but you cannot render into foreign windows
17:14 Arsen: hm, is it possible to create and share a subsurface or such? /me is unsure if those can be resized by the parent, though
17:14 Arsen: and yeah, that's what I was referring to - the wayland backend (though, maybe I'd have to hack it somewhat)
17:16 Arsen: (now, I imagine that'd require modifying the embedd*ed* client, but let's take that as acceptable in this case)
17:22 kennylevinsen: You can embed a compositor in the client yes
17:23 kennylevinsen: But it all needs to be in-process
17:23 kennylevinsen: You can render to a subsurface but it's use must also be within a surface from the same client
18:14 danieldg: if there was enough demand for this feature, something like xdg-foreign could be created to allow foreign subsurfaces to exist. But I don't think there will be such demand
18:15 danieldg: acting as a wayland proxy/pass-through compositor is more likely to be how it's done
18:18 danieldg: you could even make a defined subset of the wayland protocol just for exporting buffers (re-export just the protocols for creating a surface and buffers, along with one "it goes there" protocol)
18:22 sewn: is there a document regarding which protocols should be checked by an application? i've noticed things such as seat not be NULL-checked but things like compositor do
18:22 danieldg: the wayland protocol xml has a non-null attribute
18:22 danieldg: or maybe it's might-be-null
18:23 danieldg: regardless, it's there
18:23 sewn: sorry, where is this?
18:24 danieldg: sewn: look at wl_surface::attach
18:24 danieldg: <arg name="buffer" type="object" interface="wl_buffer" allow-null="true"
18:25 sewn: sorry i mean't if interfaces themselves can be null, such as ext-session-lock-v1's ext_session_lock_manager_v1 probability of not being offered by the compositor.
18:26 sewn: i don't see wayland applications checking if wl_seat is missing but checking if compositor or vice versa interface's managers or such is null
18:26 danieldg: sewn: ah. Technically you should check if all of them are present or not.
18:27 danieldg: however, there are a few interfaces (most in wayland.xml) that it doesn't make sense to run if they're not present
18:27 sewn: hmm, is there some document that lists interfaces that *are* guranteed to be there that wouldn't require checking?
18:27 danieldg: nope
18:27 sewn: bummer.
18:27 danieldg: none of them are tehnically guaranteed
18:28 sewn: in swaylock i see wl_compositor being checked but not wl_seat
18:28 danieldg: but if, say, wl_compositor didn't exist then almost nothing would work
18:29 sewn: hmm, okay, thanks
18:29 danieldg: sewn: the usual solution is to assume everything in wayland.xml is present, except wl_toplevel
18:29 danieldg: er, wl_shell*
18:30 emersion: that doesn't work for compositors without any currently connected output, or without any currently connected input device
18:30 emersion: swaylock doesn't check for wl_seat because it supports 0 wl_seat globals just fine
18:30 danieldg: but it would be useful if people would check for output, seat, data_device_manager, and probably a few others
18:31 danieldg: shm could be optional, and subcompositor probably could be too
18:31 emersion: danieldg: no, it would break some use-cases
18:31 emersion: in general all wayland clients _should_ support zero wl_seats, or 0 wl_outputs
18:32 danieldg: (they should also support two wl_seats)
18:32 emersion: and there's no point in requiring things you don't use, such as data device for a client which doesn't do copy/paste
18:32 emersion: or wl_subcompositor when you don't use sub-surfaces
18:35 sewn: you can have multiple seats?
18:36 emersion: yes
22:17 daniels: danieldg: cross-surface subsurfaces introduce a lot of unpleasant dependencies
22:17 daniels: it’s an obvious thing to do, but has equally been avoided for good reason
22:24 danieldg: cross-client, you mean?
22:26 danieldg: I expect there'd be some difficulty with size changes or synchronizing frames, but would that be much worse than two toplevels on the same output?