[EMAIL PROTECTED] writes:
> FVWM Bug Tracking notification
>
> new message incoming/941
>
> Message summary for PR#941
> From: [EMAIL PROTECTED]
> Subject: Icon & window stacking order glitch
> Date: Sun, 20 Oct 2002 16:59:10 -0500
> 0 replies 0 followups
>
> ====> ORIGINAL MESSAGE FOLLOWS <====
>
> From [EMAIL PROTECTED] Sun Oct 20 16:59:11 2002
> To: [EMAIL PROTECTED]
> 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.)
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 PROTECTED]
--
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 PROTECTED]
To report problems, send mail to [EMAIL PROTECTED]
