On Monday, September 8, 2003, at 06:19 PM, Dominik Vogt wrote:
On Sun, Sep 07, 2003 at 01:17:22AM -0500, fvwm-bug wrote:
FVWM Bug Tracking notification
new message incoming/1075
Message summary for PR#1075
From: [EMAIL PROTECTED]
Subject: window focus
Date: Sun, 7 Sep 2003 01:17:21 -0500
0 replies 0 followups
====> ORIGINAL MESSAGE FOLLOWS <====
Full_Name: Aaron Harwood
Version: 2.4.15-1 (fink installed)
CVS_Date:
OS: MacOS 10.2.6
X_Server: XFree86 Version 4.2.99.901 (4.3.0 RC 1) / X Window System
Submission from: (NULL) (128.250.39.70)
Reproducible Problem: Window focus becomes "corrupted". Window "A" is in
front of window "B" on the screen (perhaps completely or partially
obscurring it), however window "B" receives the focus through "A". Even
though for example the cursor is clearly within "A".
I think you somewhat confuse the concept of keyboard focus with
windows being raised or not. See the comments below. From what
you say I assume you are using ClickToFocus, but not
ClickToFocusClickRaises. To help you with your config, please
post your .fvwm2rc file to the mailing list.
Yes I did confuse the terminology, sorry. I was using MouseFocus (default). Here
is the first part of the .fvwm2rc file:
#start of .fvwm2rc
EdgeResistance 250 10
EdgeScroll 100 100
ClickTime 750
# this is put for rootless mode, because the transparent window can't be seen.
OpaqueMoveSize unlimited
IgnoreRestack
MinOverlapPercentPlacement
SloppyFocus
MouseFocusClickRaises
.
.
.
The IgnoreRestack I tried to fix the problems, including I tried putting MouseFocusClickRaises
to raise window when moved. But still problem can occur.
To reproduce: start some x terminal windows, say 2, side by side. Start
gvim, by typing gvim in one of the xterms, in such a way that the gvim
window opens and partially obscures one of the xterms. Then reposition the
obscured xterm a little bit (by dragging the title bar).
The repositioning
doesn't bring the partially obscurred xterm into the front (it is
repositioned while keeping its order),
This is usually done in the function you run on the title bar.
Raising is not in your function, but I guess that is not a problem
for you.
doesn't help...I like being able to move a window without raising it.
however fvwm2 will "think" that it
is in the front and will give focus to it through the gvim window, that is
technically incorrect.
Having the focus is completely independent of the window being
raised or not. Any window can have the focus, regardless of
whether it is obscured or not.
understood...however should a window ever have the focus if it is
_completely_ obscured? This has happened to me.
Repositioning other windows (the other xterm) _will_
bring it into the front.
I'm not sure if this is a bug. Note that although windows may not
overlap, they have an internal stacking order. If you move the
"lower" window, it disappears below the other one.
understood...I was just highlighting that _sometimes_ repositioning
seems to raise a window, sometimes it does not. In the case that it
does not raise, fvwm still thinks that it was raised and treats it as if it were on
the top of the stack when actually it is still under other windows.
Clicking on the gvim window doesn't change the
circumstance because fvwm2 thinks that it is already in the front. Clicking
on the obscurred xterm brings it into the front and works around the
problem.
A bug fix would be much appreciated. The problem occurs at many different
times (and also occurred with previous fvwm version and previous XFree86
version).
The 2.5.x beta versions allow much better control over the focus
policy. I think the following setup comes close to what you want
(with fvwm-2.5.7):
AddToFunc move_or_raise
+ C Raise
+ C Focus
+ M Move
Mouse 1 T N function move_or_raise
# The ClickToFocus stlye *must* be first as it overrides the
# other styles.
Style * ClickToFocus
Style * !FPClickDecorRaisesFocused
Style * !FPClickDecorRaisesUnfocused
Style * !FPClickDecorToFocus
Style * !FPClickToFocus
Style * !FPClickIconToFocus
I can experiment with these things (but fink doesn't install that version?).
Definitely I believe there is a bug and I can reproduce it easily. It seems to happen
whenever a new window is created and partially obscures existing windows. The partially
obscured windows will behave badly if they are manipulated.
Many thanks for you quick response, let me know if you need further input from me.
Perhaps I can demonstrate the bug using a Virtual Desktop server?
Ciao- - - - - - - - - - - - - - - - -
Dominik ^_^ ^_^
Aaron Harwood
Department of Computer Science
and Software Engineering.
The University of Melbourne.
http://www.cs.mu.oz.au/~aharwood/
