(sorry for the delayed response; been an annoyingly busy year so far...)
On Sat, Oct 23, 2021 at 04:10:01PM +0200 I heard the voice of Yumekui Neru, and lo! it spake thus: > > With a recent update of the Opera browser, its window has started > automatically raising itself whenever the mouse enters it (causing > it to receive focus). I have found that the ctwm variable > NoRaiseOnWarp mitigates the issue a bit by making Opera no longer > raise itself. Is this indicating that the cursor is warped > (in-place; it does not move) whenever it enters the window? One thing worth general notice is that "modern" Opera is now just Chrome[/ium], and so presumably inherits a rather loose understanding of interacting nicely with X and any other application from there. On this particular one, I'm gonna guess it's from the _NET_ACTIVE_WINDOW EWMH message handling. In the EWMH world, that's how a window would request that focus be given to some window; I would guess in this case it's because the X window that Operium wants to have focus isn't the top-level window you move into, so it requests the move. And that move is effectively a warpto; hence the raise and why RaiseOnWarp matters. Certainly, our _NET_ACTIVE_WINDOW handling may be making bad assumptions about how even well-behaved apps are using it, never mind the weirdness that browsers in general get up to. It may even be trying to warp to itself, which would be extra stupid (and therefore I assume it's what a browser would do ;). Anyway, you could test that easily enough by just stubbing out EwmhClientMessage_NET_ACTIVE_WINDOW() to just return at the top or something. > not to mention NoRaiseOnWarp is not restricted to specific windows > (I have not looked into the viability of patching that in) e.g. only > to Opera. That would probably be a reasonable thing to look at doing; it fits our general paradigm. Another (though more involved) thought would be to add some configurability to what EWMH messages we advertise support for. > Opera has some other strange behaviour in conjunction with > MakeTitle. If I hover over the ctwm-title of Opera (it normally > does not create a titlebar) the titlebar will sometimes flicker > rapidly. This may be related to Chrome's using the Motif hints to disable titlebars/borders (mentioning MakeTitle suggests you're overriding it there). There's a setting in Chrome to turn that off, something like 'use system decorations' or the like, and I presume it's available somehow in the Opera skins. I'd guess it's an interaction around that, so just flipping the config setting to make Opera stop trying to turn off the titlebar in the first place may resolve it. > It appears this is related to the option `TransientOnTop int%` -- if > I set it to a high value, modals (transients) again remain on top > even with NoRaiseOnWarp set. Could be just a nice simple overflow. trans_area = trans->frame_width * trans->frame_height; main_area = main->frame_width * main->frame_height; return (trans_area < ((main_area * Scr->TransientOnTop) / 100)); An 1920x1080 window has an area of 2 million pixels, 2 million times 4 thousand is 8 billion, which has already wrapped a 32-bit signed int 4 times. It may be worth changing this over to just do some FP math instead, like we did years back with OpaqueResize stuff. Or making high enough values infinite, like we did on the OpaqueMove as well as Resize; if you're over 100% on TOT, it's a stretch to imagine you'd ever be meaning for it _not_ to trigger... > If I on the other hand run the program and move my mouse out of the > modal and over the parent and then press Esc, the modal will close > and it will look like the parent gains focus (its border highlights). I see something similar with Audacious, where popping up and closing a dialog (like the playlist) visually restores the focus to the main window but doesn't actually, so I have to move the mouse out and back in. I haven't looked deeper into what's going on, but Audacious is also a QT program, and I haven't seen similar behavior on GTK stuff, so that might indicate a direction to look. > Since programs run in Wine can have a tendency to not be very nice > or well-behaved, I would say this last issue probably is not worth > focusing[ c: ] on here, though I thought I could mention it. Yeah, nothing comes to mind on that one, except, yeah, Wine... > Bonus issue I just remembered -- Firefox tooltips in conjunciton > with opening the gtkfilechooser will sometimes linger on top of the > filechooser window, and will not disappear until the filechooser is > closed. [...] This is just speculation from my side though. Well, FF won't take any events on the main window while the dialog is open, so it probably follows from that somehow. Though the tooltips might, like the right-click menus, be their own top-level windows too, which can make things odder... -- Matthew Fuller (MF4839) | fulle...@over-yonder.net Systems/Network Administrator | http://www.over-yonder.net/~fullermd/ On the Internet, nobody can hear you scream.