On Thu, 22 Aug 2002 21:31:38 -0500
FVWM CVS <fvwm-workers@fvwm.org> wrote:
> CVSROOT: /home/cvs/fvwm
> Module name: fvwm
> Changes by: drbob 02/08/22 21:31:38
>
> Modified files:
> . : ChangeLog
> fvwm : events.c focus.c focus.h stack.c stack.h
>
> Log message:
> Experimental RaiseOverUnmanaged Handling - an attempt to fix the
> interaction of RaiseOverUnmanaged with various focus policies,
> particularly mouse focus + client click raises.
To recap briefly:
1) This is an attempt to fix the old "MouseFocusClickRaises breaks double-click
handling in xfm" problem.
2) The problem is caused by the RaiseOverUnmanaged hack in stack.c
(is_on_top_of_layer): formerly it always returned false to force a raise because
we couldn't know whether there was an override_redirect window abovr the target
window. This had the unwanted side effect of causing button grab timing that
didn't work well with MFCR, and caused certain XtLib programs to miss
double-clicks due to extraneous Enter/LeaveNotify events.
3) This fix adds a query of the server's window tree and a search for any
superior OR windows if the target is at the top of the FvwmWindow stack and
RaiseOverUnmanaged is in effect.
4) We don't want to query the server on every call to iotol - there are just too
many of them; so the trick is to find the one spot where the caller really needs
to know the true "on-top" status with regard to OR windows.
5) I thought I had identified this spot, ran the test code for a couple of days,
and committed it. According to some immutable natural law governing such
matters, a few minutes later I dragged out yet another app with an OR splash
window to test, and the new code failed to raise the target window over it.
6) I'll be committing an update shortly that looks intuitively like it shouldn't
work, but does. I can't explain it yet. I can only surmise that Dominik's
rewritten focus & grab code was impeccably correct as far as the timing of grabs
before I tweaked it, so long as iotol didn't return any false negatives.
7) Dominik -- the new version effectively no-ops most of the first version by
reverting to the original handling in HandleEnterNotify; instead it calls the
server-query version of iotol from HandleButtonPress. (Calling the old iotol
would override the effect of the previous call from HandleEnterNotify. I don't
understand why this didn't always fail before.)
Cheers,
Bob
--
Visit the official FVWM web page at <URL:http://www.fvwm.org/>.
To unsubscribe from the list, send "unsubscribe fvwm-workers" in the
body of a message to [EMAIL PROTECTED]
To report problems, send mail to [EMAIL PROTECTED]
