Subject: Notification: incoming/1075

From: [email-masked]
Date: Sun, 07 Sep 2003 01:17:22 -0500

FVWM Bug Tracking notification

new message incoming/1075

Message summary for PR#1075
	From: [email-masked]
	Subject: window focus
	Date: Sun, 7 Sep 2003 01:17:21 -0500
	0 replies 	0 followups

====> ORIGINAL MESSAGE FOLLOWS <====

>From [email-masked] Sun Sep 07 01:17:22 2003
Date: Sun, 7 Sep 2003 01:17:21 -0500
From: [email-masked]
To: [email-masked]
Subject: window focus

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

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), however fvwm2 will "think" that it
is in the front and will give focus to it through the gvim window, that is
technically incorrect. Repositioning other windows (the other xterm) _will_
bring it into the front. 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).
--Aaron

--
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-masked].
To report problems, send mail to [email-masked]

---

From: Dominik Vogt <[email-masked]>
Date: Mon, 8 Sep 2003 10:19:58 +0200

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

> obscured xterm a little bit (by dragging the title bar).

> The repositioning
> 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.

> however fvwm2 will "think" that it
> 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.

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

> Clicking on the gvim window doesn't change the

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

Ciao

Dominik ^_^  ^_^

---

From: Aaron Harwood <[email-masked]>
Date: Mon, 8 Sep 2003 18:42:08 +1000

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

> Raising is not in your function, but I guess that is not a problem

doesn't help...I like being able to move a window without raising it.

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

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

>   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?

> Dominik ^_^  ^_^
- - - - - - - - - - - - - - - - -
Aaron Harwood
Department of Computer Science
and Software Engineering.
The University of Melbourne.
http://www.cs.mu.oz.au/~aharwood/