(17-08-2020, 10:10 AM)vain Wrote: xprompt (and dmenu, for that matter) try to throw the WM off its throne. They use override_redirect to try to avoid any interference by the WM in the first place. Then, they grab focus. Not once, but repeatedly until they get it.

Indeed. But because of the nature of both applications, they cannot be treated as a regular window, they must be treated as a popup menu. EWMH has a property for it: setting _NET_WM_WINDOW_TYPE to _NET_WM_WINDOW_TYPE_MENU makes wms ignore the window or draw it as a menu (above the others). But not all wm support EWMH, while almost all of them respects override_redirect.

(17-08-2020, 10:10 AM)vain Wrote: On top of that, I hadn’t even considered that override_redirect clients might steal focus, probably because focus handling is confusing enough with regular clients.

I also have not considered the case for focus-stealing windows that are override_redirect. But in respect to which windows steal focus, override_redirect-set ones are the most likely to do it.

Exploring a little bit, I came out with this solution for the function that handle FocusIn events in my wm (don't know if it works on katriawm):
My client_focus() is your manage_xfocus(), and my 'selmon->focused' is your 'focus'.

Before that I considered handling FocusOut event, as I said to you in IRC, but I have no idea how the events come or their order.

(17-08-2020, 10:10 AM)vain Wrote: From a pragmatic point of view, it’s probably best to not change focus unless you really have to. That is, do what dmenu does and only touch focus when running embedded.

(I might be biased here, because that approach means I can use xprompt without having to add more workarounds to my WM. :))

I really know almost nothing about input methods, but I think it needs the window to be focused, not "fake-focused" like just grabbing key events.
But I can try following this approach; after all, it's just one line to be commented out on xprompt.c! Embedded xprompt keeps stealing focus from its parent anyway.