(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.
