Hi Dominik,
I've adjusted the subject line to distinguish my remaining problem (thanks
to you and others on this list, of the other two, one has been fixed and I
have a patch for the other). The following tests are all with a local
fvwm-snap-20010510, built under Cygwin 1.3.1 on Windows 2000, and Exceed
6.2.0.16 as X-server.
On 01 May 2001, I wrote:
>
> 1) I use ClickToFocus. This mostly works correctly with X and
> native windows together, but if the active X-window is behind
> a native window, it is raised if the cursor moves over it
> [...]. I tried turning on BugOpts
> RaiseOverNativeWindows, but this doesn't seem to make any
> difference (I guess it's switched on automatically). As one
> might expect, turning it off prevents X-windows being raised
> over the native window at all (even by a click).
and on 06 May 2001, Dominik Vogt <dominik.vogt_at_gmx.de> wrote:
>
> I searched up and down the code but I can't find any way how
> simply moving the pointer over the focused window could trigger
> raising or lowering windows. You said that turning of the
> RaiseOverNativeWindows option 'fixes' the problem. This proves
> that the RaiseOrLowerWindow() function is called when the pointer
> enters the window because it is the only place where the option is
> evaluated. But fvwm does not call this function.
I added debug messages to RaiseOrLowerWindow() and confirmed that it is not
called when I get this mysterious "autoraise". I have however found some
more clues that might help track down the cause of this problem.
First, I have found some option settings that seem to "cure" the autoraise
problem (but in other respects aren't much to my liking). I also narrowed
down my .fvwm2rc to the simplest that demonstrates it. With just the
following .fvwm2rc (and nothing else), I get the autoraise problem:-
Style * ClickToFocus
BugOpts RaiseOverNativeWindows
EdgeScroll 0 0
EdgeThickness 0
DeskTopSize 1x1
However if I comment out (or explicitly set default values for) the
EdgeScroll, EdgeThickness, and DeskTopSize lines, the problem goes away. If
*any* of the above settings is restored, then the problem returns. This is
very curious, as the connection between window raising and the desktop size
/ scrolling functions seems obscure.
Unfortunately, even with those lines removed, the behaviour still isn't
perfect (though much better). Now the active X-window isn't raised over a
native window, even when I click in it - I have to click on the title bar or
borders. Contrariwise, inactive X-windows are raised correctly if I click
inside the window.
Another observation: although most application windows (eg. FvwmForm, xterm,
emacs, rclock) show the autoraising problem, xlogo and xclock don't. What's
different about these guys? In particular, rclock and xclock seem pretty
similar, but the former shows the autoraise bug.
Finally, I had a look with Exceed's tracing facility. I'm not really
qualified to interpret the results, but I hope I've extracted the relevant
portion that someone else can understand. I append the results to this
message (please let me know if you want more detail).
Does any of this help diagnose the problem?
Thanks,
Tim.
============================== cut here ==============================
Extracts from Exceed trace logs
===============================
The format seems to be (taking the first line below as an example): packet
71, 648723 milliseconds from server start, socket 1, protocol request number
42, protocol request name SetInputFocus. This is followed by the request
parameters.
This first sequence occurred when I moved the mouse from a native (Notepad)
window over to an active X-window (xterm) which partially concealed behind
it. The xterm window was (incorrectly) raised (and received input focus).
71: [648723.340] (1) --> Request 42 SetInputFocus
revert to Parent
focus 0x100000e
time CurrentTime
73: [648723.0] (1) <-- Event 9 FocusIn
sequence # 0x52e2
detail NonLinear
event 0x100000e
mode Normal
77: [648743.20] (1) <-- Event 12 Expose
sequence # 0x52e2
window 0x4000d6
xy [225, 0]
width x height 403 x 7
count 2
77: [648743.0] (1) <-- Event 12 Expose
sequence # 0x52e2
window 0x4000d6
xy [621, 7]
width x height 7 x 160
count 1
77: [648743.0] (1) <-- Event 12 Expose
sequence # 0x52e2
window 0x4000d6
xy [225, 167]
width x height 403 x 7
count 0
78: [648743.0] (1) <-- Event 12 Expose
sequence # 0x52e2
window 0x4000e0
xy [218, 0]
width x height 396 x 16
count 0
80: [648753.10] (4) --> Request 76 ImageText8
drawable 0x1000015
gc 0x1000018
xy [37, 17]
text " "
... followed by lots more.
Next, I did the same, but this time with an inactive xterm window, also
behind the native window. The only result was:-
295: [686548.160] (1) <-- Event 18 UnmapNotify
sequence # 0x5313
event 0x2a
window 0x42
from configure false
297: [686548.0] (1) <-- Event 7 EnterNotify
sequence # 0x5313
detail NonLinearVertical
time 686548
root 0x2a
event 0x80000e
child 0x800015
root xy [437, 600]
event xy [406, 121]
state 0
mode Normal
focus false
same screen true
Finally, I clicked on the inactive xterm window, bringing it to the front.
560: [215050.541] (3) <-- Event 9 FocusIn
sequence # 0x9f
detail Pointer
event 0xc0000e
mode Normal
561: [215050.0] (1) <-- Event 9 FocusIn
sequence # 0x18af
detail Pointer
event 0xc0000e
mode Normal
563: [215070.20] (3) --> Request 76 ImageText8
drawable 0xc00015
gc 0xc00018
xy [37, 17]
text " "
565: [215150.80] (3) <-- Event 8 LeaveNotify
sequence # 0xa0
detail Virtual
time 215150
root 0x2a
event 0xc0000e
child 0xc00015
root xy [180, 780]
event xy [164, 133]
state Button1
mode Grab
focus true
same screen true
... followed by lots more.
============================== cut here ==============================
Tim Adye, BaBar/DELPHI Groups, Particle Physics Dept., _ /|
Rutherford Appleton Laboratory, UK. \'o.O' Oop!
e-mail: T.J.Adye_at_rl.ac.uk or VXCERN::ADYE (HEPNET/SPAN) =(___)= Ack!
WWW:
http://hepwww.rl.ac.uk/Delphi/Adye/homepage.html U Thphft!
--
Visit the official FVWM web page at <URL: http://www.fvwm.org/>.
To unsubscribe from the list, send "unsubscribe fvwm" in the body of a
message to majordomo_at_fvwm.org.
To report problems, send mail to fvwm-owner_at_fvwm.org.
Received on Thu May 17 2001 - 19:51:37 BST