Subject: Notification: incoming/941

From: [email-masked]
Date: Sun, 20 Oct 2002 16:59:11 -0500

FVWM Bug Tracking notification

new message incoming/941

Message summary for PR#941
	From: [email-masked]
	Subject: Icon & window stacking order glitch
	Date: Sun, 20 Oct 2002 16:59:10 -0500
	0 replies 	0 followups

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

>From [email-masked] Sun Oct 20 16:59:11 2002
From: [email-masked]
To: [email-masked]
Subject: Icon & window stacking order glitch
Date: Sun, 20 Oct 2002 16:59:10 -0500

Full_Name: Chris Siebenmann
Version: 2.4.12
CVS_Date: 
OS: Red Hat Linux 7.3
X_Server: XFree86 4.2.1
Submission from: (NULL) (128.100.102.51)

 If I iconify a window (in a style where the icon winds up on the root
window, not swallowed into an FvwmIconManager or the like), the icon is
more or less stuck below all non-icon windows regardless of attempts to
manipulate the stacking order. Everything appears to be on the default
layer (layer 4 in my case), according to FvwmIdentify.

 If I perform operations that cause fvwm to refresh the icon, such
as flipping to another virtual screen and then back or moving a
window (with OpaqueMove) such that the icon is partly exposed, the
icon will temporarily pop into visibility in its proper stacking
order. If I raise and then relower an obscuring window, poof the
icon disappears again.

 This bug is not entirely consistent; there are some icons that it
doesn't happen to. I can't see a discernable pattern in what they
are, unfortunately.

 I do not use an IconBox ('Style * IconBox none').
 I can't think of any other relevant styles or elements of my
FVWM configuration. (If I am wrong about this, please let me know
and I will be happy to fill in any necessary details.)

 I was previously running FVWM 2.4.3, which did not behave like this.

 I am willing to test patches. (Eager, in fact, as I'm finding this
glitch to be quite annoying; I may have to revert to fvwm 2.4.3
temporarily.)

--
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, 21 Oct 2002 13:16:30 +0200

> glitch to be quite annoying; I may have to revert to fvwm 2.4.3

For a start, detailed instructions to reproduce this would be
helpful.  Please try to describe it step by step and attach an
fvwm configuration that shose the problem.

Bye

Dominik ^_^  ^_^

 --
Dominik Vogt, mail: [email-masked], phone: 0721/91374-382
Schlund + Partner AG, Erbprinzenstr. 4-12, D-76133 Karlsruhe
--
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: Chris Siebenmann <[email-masked]>
Date: Mon, 21 Oct 2002 17:08:20 -0400

I did some more digging on my problem of Lower not lowering windows
below iconified windows.
 It first appears in fvwm 2.4.10; it is not present in 2.4.9.

 Reproduction steps with the fvwm2rc at the end of this message:
- start your favorite Xnest environment (or a real X server) and
  fvwm as 'fvwm2 -f fvwm2rc-test'.
  The fvwm2rc uses button 3 on the root window to pop up a menu
  of operations and uses manual placement of windows.
- pop up the root menu; pick XTerm; place the resulting window
  somewhere.
- pop the root menu up, pick Iconify, button-1 the xterm window
  to iconify it.
- pop the root menu up, pick XTerm, place the resulting xterm
  window so that it completely obscures the iconified XTerm.
- pop the root menu up, pick Bottom, chose the (new) XTerm window.
  On fvwm 2.4.9 and below the iconified XTerm icon appears on top
  of the uniconified xterm. On 2.4.10 and later, nothing happens.
- on 2.4.10+, then pop the menu up, pick Move, pick the XTerm window.
  Move the window slowly so as to reveal the iconified XTerm.
  When a tiny bit of the icon appears, it will suddenly jump
  into full appearance over the window you are moving (as it should
  be).

[I believe xlogo32 should be universally available; if not, substitute
 the default icon of your choice.]

	- cks
Minimal .fvwm2rc:
# Minimal .fvwm2rc to reproduce my icon bug.

DestroyMenu Blit
AddToMenu Blit	"XTerm"	Exec xterm &
+	"Top"		Raise
+	"Bottom"	Lower
+	"Move"		Move
+	"Iconify"	Iconify
# done Blit.

Mouse	1	I	N	Iconify
Mouse	3	R	N	PopUp Blit

OpaqueMoveSize	100

Style "*"	SloppyFocus, ManualPlacement, IconBox None, Icon xlogo32
Style "XTerm"	NoTitle, HandleWidth 5, BorderWidth 5
--
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: Chris Siebenmann <[email-masked]>
Date: Tue, 22 Oct 2002 00:36:02 -0400

An additional two notes:

 I localized the problem to fvwm 2.4.10's fvwm/stack.c changes; the 2.4.9
stack.c (hacked to change '->pstack' to '->stack.p') doesn't exhibit the
problem when compiled into 2.4.10.

 The problem appears to go away if I force the do_lower parameter to
fvwm/stack.c's restack_windows() to be zero. I suspect that this is
not the actual answer, but I lack the understanding of fvwm's internals
to understand what I just broke. (Everything seems to work fine for me,
but I don't use multiple layers.)

	- cks

---

From: Dominik Vogt <[email-masked]>
Date: Tue, 22 Oct 2002 11:32:02 +0200

> problem when compiled into 2.4.10.

Yes, I know.  I do know when these problems appeared, just not why
they appeared :-)

> to understand what I just broke.

Don't worry, nobody understands that heap of dung.  That is a
questiong of bad design, not of fvwm internals knowledge.

I reviewed the stacking code yesterday, and it is rife with bugs.
For the moment I do not need any additional input on the problem
because when you give it is probably already outdated.  I will
report back when I think I got all of the problems.

Bye

Dominik ^_^  ^_^

---

From: Dan Espen <[email-masked]>
Date: Tue, 22 Oct 2002 11:06:21 -0400

> glitch to be quite annoying; I may have to revert to fvwm 2.4.3

Fvwm has 2 Style options that affect application controlled
window placement:

              NoPPosition  instructs  fvwm  to  ignore the
              program specified position (PPosition  hint)
              when adding new windows.  Using PPosition is
              required for some applications, but  if  you
              don't have one of those its a real headache.
              Many programs  set  PPosition  to  something
              obnoxious like 0,0 (upper left corner).

              NoUSPosition   works  like  NoPPosition  but
              applies suppresses using the user  specified
              position  indicated  by the program (USPosi
              tion hint).  It is generally a bad thing  to
              override  the user's choice, but some appli
              cations misuse the USPosition hint to  force
              their  windows  to  a  certain  spot  on the
              screen without the user's consent.

If the window in question is a transient, there's another
option you can find in the man page.

Could you investigate how these options affect your problem
and get back to us?

Thanks,
-- 
Dan Espen                           E-mail: [email-masked]

---

From: Dominik Vogt <[email-masked]>
Date: Wed, 23 Oct 2002 01:03:46 +0200

> but I don't use multiple layers.)

I think I got all the bugs.  The stacking code is always a rich
source of bugs.  Within 24 hours I found no less than six, some
introduced in 2.4.10 or later and some just hidden by fortunate
circumstances or uncontrolled side effects in earlier versions.
Expect the 2.4.13 release within a week.  It would be nice if you
could download the latest code from the 2.4 branch in cvs and
double check wether all problems are gone:

  $  cvs -d :pserver:[email-masked]:/home/cvs/fvwm co -r branch-2_4 -d fvwm-2.4 fvwm

(this checks out the 2.4 branch into a directory fvwm-2.4).

Bye

Dominik ^_^  ^_^

 --
Dominik Vogt, [email-masked]
Reply-To: [email-masked]

---

From: Chris Siebenmann <[email-masked]>
Date: Thu, 24 Oct 2002 02:56:48 -0400

In testing so far, a CVS version from branch-2_4 pulled on Tuesday
night or so seems to be working fine. (Sorry for the delay in reply,
but I wanted to give it some time to make sure.) Certainly the stacking
issue I saw is gone and I haven't observed any other ones.

	- cks