Fix event propagation on Openbox

[Caellian]

Events now get correctly propagated to a window (or desktop if none) behind conky instead of always to desktop.

This PR addresses some of the issues raised in #1767, but it's mainly correcting event propagation/passing.

This was a necessary change to handle cases such as MATE+caja where caja is used between conky and background to show icons and desktop menu.

[netlify]

✅ Deploy Preview for conkyweb canceled.

Name	Link
🔨 Latest commit	2bfe8bb
🔍 Latest deploy log	https://app.netlify.com/sites/conkyweb/deploys/661421ff20f90100087a9bf1

[Caellian]

Detecting the window below conky breaks openbox because it does something weird with the window tree:

0x201369 (has no name): ()  253x102+44+44  +44+44
        24 children:
        0x2200001 "conky (torchwood)": ("Conky" "Conky")  253x102+0+0  +44+44
        0x201395 (has no name): ()  1x1+0+0  +44+44
        0x201394 (has no name): ()  1x1+0+0  +44+44
        0x201393 (has no name): ()  1x1+0+0  +44+44
        0x201392 (has no name): ()  1x1+0+0  +44+44
        0x201391 (has no name): ()  1x1+0+0  +44+44
        0x201390 (has no name): ()  1x1+0+0  +44+44
        0x20138f (has no name): ()  1x1+0+0  +44+44
        0x20138e (has no name): ()  1x1+0+0  +44+44
        0x201389 (has no name): ()  1x1+0+0  +44+44

I've seen a similar thing happen on Plasma...

[Caellian]

openbox [...] it does something weird with the window tree

Not sure what it is, spent an hour looking for it online but there's no mention of it anywhere. I left the previous impl as a fallback and rely on atoms instead now - so openbox works again. I think _NET_CLIENT_LIST "SHOULD" be common enough. There's ways to improve correctness (like manual ordering based on depth in window attributes if _NET_CLIENT_LIST_STACKED is not defined), but I'm burnt out for now and they seem wasteful.

MATE still doesn't work, that's next I guess.

[Caellian]

MATE uses caja, which uses gtk. No events get properly passed through, but I'm focusing on right-click which should open a context menu.

Gdk starts handling menu opening with gdk_x11_toplevel_show_window_menu, in gdk/x11/gdksurface-x11.c, which is then translated into a GdkEvent (through very complicated and long pipeline of handlers,signals,converters,...), but up to the point where high level "get events" function is, nothing seems to be checking whether the right-clicked surface is below pointer, nor whether the click event was synthetic (which was my previous hunch).

It seems Gdk only accepts Xinput pointer events, which is why it ignores the basic X11 ones.

[Caellian]

There's a bunch more, but we're not forwarding those events so I didn't implement all of them.

[brndnmtthws]

PR looks good, one minor nit.

[lodgerz]

thanks for fixing the bug. it happened to me too on openbox: due to conky the cpu reached 40% and the temperature over 60°, then by killing conky everything went back to normal.

If you're interested, I found a way to reproduce the bug:

1. open lxappearance and change the theme (one at random)
2. close and reopen chromium and save a random image (the problem starts when the chromium file manager opens, I think it uses gtk3)