00:45 <Nosrep> oh thats crazy

00:46 <Nosrep> so the ss itself has transparency?

04:58 <leon-p> ifreund: that sounds ... hacky. FWIW a few years ago I was plaing around with adding a river mode that bound j / k to calling wtype to generate virtual arrow-key presses to scroll firefox. The latency was horrible (and lead me onto that custo keyboard layout quest if you remember)

05:56 <ifreund> leon-p: latency should be much better without the startup time of wtype included I think

05:57 <ifreund> and yeah its kinda hacky, but I think its a valid thing to want to do and I would like it to be possible if it doesn't get in the way of other more important things

05:57 <ifreund> Nosrep: yep, the screenshot itself can be transparent

05:58 <ifreund> i.e. not composited with the rest of the desktop

06:24 <FireFly> perfect for taking screenshots of xeyes

06:24 <FireFly> (well uh, assuming that would still work for xwayland clients, but.. I guess so?)

06:44 <ifreund> dunno about xwayland, maybe not

14:37 <pkap> About screensharing with the new protocol. If a toplevel is shared (say zoom via wlr-portal), but not rendered on the output, e.g. the toplevel is on another tag. What dimensions of the toplevel will be screenshared?

14:38 <vyivel> the last ones probably

14:49 <pkap> Or do all toplevels have a buffer in memory with certain dimensions, even if it's not rendered currently?

14:54 <pkap> Then this buffer would be shared I assume?

15:02 <leon-p> pkap: whether a client renders a window is orthogonal to whether it's displayed. the former is necessary for screencapture (unless the server caches the last committed buffer), the letter isn't

15:22 <pkap> leon-p: I see. That makes sense. So the client is unaware if it's displayed or not and therefore it will keep and update the buffer?

15:22 <pkap> Sorry for the probably very basic questions

15:23 <leon-p> yes and no, depends on how it's rendering loop is setup

15:25 <leon-p> some programs, like f.e. a load graph widget, needs to update, say, every X seconds. It has a rendering loop like { render(); sleep(X); }. Applications which have f.e. animations constantly on screen will likely use frame callbacks (or one of the fancy new synchronisation protocols) to synchronise rendering with the physical display. Games on the other hand are usualy very badly programmed and have a brute force rendering loop that just renders as fast as po

15:25 <leon-p> ssible

15:26 <leon-p> a client tying it's rendering to frame callbacks will stop rendering if it receives no frame callbacks. The server may stop sending them when the client isn't displayed

15:26 <leon-p> however, the server will likely send frame callbacks again if the client is actively screen-copied

15:27 <leon-p> the last commited buffer will be kept either way

15:32 <pkap> Cool, that's good to know

16:03 <szgy> ifreund: text-input-protocol could allow smth _kinda_ like global vim keybinds??

16:09 <leon-p> yes and it already works, just with high latency

16:10 <leon-p> i.e. you could bind `wtype -k up` to k

16:10 <leon-p> which would cause k to spawn wtype to generate a virtual event of an up-arrow press

16:11 <leon-p> but due to the startup latency right now it's not feasible, but a river WM could also just use that protocol directly, eliminating the startup time

16:11 <leon-p> maybe I'll try it in antares, see how well it works

16:57 <szgy> nice

19:03 <pkap> There are tools doing something similar with the /dev/input and uinput in think.

19:26 <donio> from what i can tell only the text-input protocol approach would allow ensuring that the input goes to a particular window right? (rather than whatever happens to be focused)

19:35 <vyivel> iirc text-input focus must match keyboard focus as per protocol

19:35 <vyivel> but also nothing stops the compositor from just Lying and focusing multiple windows at the same time if they're from different clients