On Fri, May 18, 2001 at 01:50:57AM +0100, Adye, TJ (Tim) wrote:
> 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.
You must have made some mistake. If the function were not called
then turning off
BugOpts RaiseOverNativeWindows off
would not have "fixed" your problem. What I wanted to say was
that fvwm does not call the function on its own when the pointer
enters a window (or receives focus).
> 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.
The problem seems to be related to the "pan frame" windows, small
invisible windows that surround the viewport that are used for
page scrolling. It seems that your problem occurs only if there
are no pan frame windows. The corresponding code in
checkPanFrames() was a bit confusing, so I rewrote it partially.
The pan frame windows are raised from several places throughout
the code to make sure they are on top of everything else - even
above native windows. So this is the relation to your problem.
> 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.
It seems that fvwm thinks these windows are already on top and do
not need to be raised when clicked anymore. I think I have fixed
this one.
> 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.
xclock and xlogo do not accept the keyboard focus therefore they
can never be focused, and since only the focused window shows the
problem, they don't. Try
Style xclock Lenience
and you will see the same problem for xclock.
> 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).
Um, didn't you say that the X window already had the focus? Does
this mean that Exceed takes away the keyboard focus from the X
window as soon as the pointer moved over a native window? Even
with ClickToFocus? Perhaps there is some kind of auto raising
under windows. Doesn't it bring a window to the front as soon as
it receives focus?
> 71: [648723.340] (1) --> Request 42 SetInputFocus
>
> revert to Parent
> focus 0x100000e
> time CurrentTime
>
...
Hm, wasn't there any EnterNotify or ConfigureRequest? Okay, it
seems that focusing the window triggers the problem somehow
Bye
Dominik ^_^ ^_^
--
Dominik Vogt, dominik.vogt_at_gmx.de
Reply-To: dominik.vogt_at_gmx.de
--
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 Tue May 22 2001 - 15:52:12 BST