Subject: [50 character or so descriptive subject here (for reference)]

From: [email-masked]
Date: Mon, 6 Sep 1999 00:38:39 -0500 (CDT)

Configuration Information [Automatically generated, do not change]:
uname output: Linux dethstar 2.0.38 #1 Sat Aug 28 13:31:40 CDT 1999 i586 unknown
Compiler: gcc
Compilation CFLAGS: -g -O2
prefix: /usr/local
sysconfdir: /usr/local/etc
libexecdir: /usr/local/libexec

FVWM Version: 2.3.8
FVWM_CONFIGDIR: unset
FVWM_MODULEDIR: unset
FVWM_USERHOME: unset

Description:
	Raising and lowering of windows does not work right when GNOME
	is running. The Panel's always below other windows setting is
	ignored. Instead, raising a window makes it go below the panel
	and lowering it makes it go above! Also, the only way to raise
	a window is with Alt-Tab. The weirdest thing is that it doesn't
	always behave this way. For example, raising and lowering windows
	works fine at the moment, but all windows are below the panel.

Repeat-By:
	Just run GNOME.
--
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: Bob Woodside <[email-masked]>
Date: Mon, 06 Sep 1999 03:32:25 -0400

[email-masked] wrote:
>         ignored.

	[sigh!] Can someone familiar with GNOME tell us whether the Panel is
another of those [expletive deleted] override_redirect thingies that
seem to have become fashionable of late?

Cheers,
- Bob

---

From: Neil Bird <[email-masked]>
Date: Mon, 06 Sep 1999 10:29:16 +0100

> seem to have become fashionable of late?

  I had a thought about this over the W/E; maybe I'm missing something
obvious, but I have a suggestion - which relies on something I *think* is
infvwm. Hang on, I'll check ...

  OK, yes it's there, but I've not used it so I may misdescribe it.

  Would it not be possible (well, maybe 'acceptable' would be better) to
have logic in fvwm such that, instead of blindly ignoring (and keeping on
top/page/etc.) override_redirect windows, if a Style exists (i.e., created
by the users that want it) by the name of "OverrideRedirect" then these
windows have that style [and only that style/ Prob. not].

  Then, if the user *really* wants override_redirect to be that, they do
nothing. Those of us who're dischuffed with the concept may choose to:

  Style "OverrideRedirect" \
    Sticky, NoTitle, NoBorder, WindowListSkip, CirculateSkip, Level 0

  That last should be "put on top layer".

  I personally would then just have no title/border.

  Might it not even be an idea to define that style by default and always
process override_redirect (that's possibly overstepping the mark!).

  Just a thought, but it would seem to solve most of the OR problems
that've cropped up. Ideally, in the fullness of time, 'OverrideRedirect'
would become a conditional/windowlistable tag, akin to Raised or Iconic.

-- 
=====================- http://www.racaldefence.com/ -===================
 Neil Bird                   |   This is who we are     The time is near
                             |
 mailto:[email-masked] |        There are 117 days remaining
--
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: Matthias Clasen <[email-masked]>
Date: Mon, 6 Sep 1999 11:35:50 +0200

> would become a conditional/windowlistable tag, akin to Raised or Iconic.

I guess you can expect at least some OR programs to break when their
top-level windows are suddenly reparented away under them. 

-- 
Matthias Clasen, 
Tel. 0761/203-5606
Email: [email-masked]
Mathematisches Institut, Albert-Ludwigs-Universitaet Freiburg
--
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, 6 Sep 1999 11:37:20 +0200

> 	works fine at the moment, but all windows are below the panel.

The panel sets layer hints that are honoured by a GNOME compliant
window manager like fvwm.  It can tell the WM that it wants to stay
on a layer above or below all normal windows.  I reaaly don't know
why KDE/GNOME do it this way with several of their desktop accessories,
but it's regularly driving the users nuts.  Fortunately you can tell
fvwm to override this setting:

  Style panel StaysPut

This command places the window on the default layer where all other
normal windows reside.  Thus it can be raised/lowered as usual.

The strange effect with windows going in the opposite direction of
where they are supposed to is probably caused by the panel flipping
its layer.

Bye

Dominik ^_^
-- 
Dominik Vogt, Hewlett-Packard GmbH, Dept. BVS
Herrenberger Str.130, 71034 Boeblingen, Germany
phone: 07031/14-4596, fax: 07031/14-3883, [email-masked]
--
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: Tim Phipps <[email-masked]>
Date: Mon, 06 Sep 1999 11:01:21 +0100

> windows have that style [and only that style/ Prob. not].
Fvwm does not blindly ignore OR windows.  It never sees them.  The
override_redirect flag is used by the server when a window is created
and what it does it to override the redirection of map request to the
window manager.

What normally happens with fvwm is that a client creates a window and
maps it with XMapWindow(). This causes a map request to be sent from the
client to the server.  Because fvwm has set the substructure_redirect
bit on the root window the server does not map the window, instead it
passes the request on to fvwm to deal with. Fvwm then sees this request
and can reparent the window and put borders and things on it.

With override_redirect windows the server ignores the
substructure_redirect tha fvwm has and just maps the window.  Fvwm does
not know anything has happened and cannot do anything about it.

In summary: you can't have an OverrideRedirect style.  If a client uses
override_redirect you are stuck with the way it chooses to behave.  My
opinion is that OR shouldn't be used for anything but pop-up menus,
anyhting else is bad manners.

Cheers,
Tim.

---

From: Neil Bird <[email-masked]>
Date: Mon, 06 Sep 1999 11:08:30 +0100

> anyhting else is bad manners.

  Oh well. It was a nice thought while it lasted :-/

---

From: Dominik Vogt <[email-masked]>
Date: Mon, 6 Sep 1999 12:42:16 +0200

> anyhting else is bad manners.

It's not only bad manners, it's against the law - er, I mean against
the ICCCM. Applications creating windows like the KFM icons are breaking
the ICCCM which explicitly states the the WM may do anything it likes
when it detects such a window.

Bye

Dominik ^_^

---

From: Bob Woodside <[email-masked]>
Date: Mon, 06 Sep 1999 16:18:56 -0400

Dominik Vogt wrote:
> window manager like fvwm....

	Dominik, I take it that this means that Panel is *not* another of the
override_redirect bad boys. Yes?

Cheers,
Bob

---

From: "Eric Gillespie, Jr." <[email-masked]>
Date: Mon, 6 Sep 1999 15:24:38 -0500

On Mon, Sep 06, 1999 at 11:37:20AM +0200,
> where they are supposed to is probably caused by the panel flipping

Thanks, that fixed it. The reason I thought it was a problem with FVWM
is that Enlightenment didn't have this problem. Next time I won't blame
FVWM so quickly. :)

-- 
Eric Gillespie, Jr. <*> [email-masked]

"Man is a rope, tied between beast and overman--a rope over an abyss.
 A dangerous across, a dangerous on-the-way, a dangerous looking-back,
 a dangerous shuddering and stopping."
 --Friedrich Nietzsche

---

From: "Eric Gillespie, Jr." <[email-masked]>
Date: Mon, 6 Sep 1999 23:02:15 -0500

> where they are supposed to is probably caused by the panel flipping

Sorry, this did not solve the problem.

---

From: Olivier Chapuis <[email-masked]>
Date: Tue, 07 Sep 1999 07:02:40 +0200

> Sorry, this did not solve the problem.

Hello,
You may try to add the following (in plase of Style panel StaysPut)

DefaultLayers 6 8 10

This was suggested by Dominik 2 months ago.
Hope this help (I am not sure to understand the real problem).
Olivier

---

From: Dominik Vogt <[email-masked]>
Date: Tue, 7 Sep 1999 13:06:20 +0200

> override_redirect bad boys. Yes?

Yup.

Dominik ^_^

---

From: Olivier Chapuis <[email-masked]>
Date: Tue, 07 Sep 1999 13:05:02 +0200

> fvwm to override this setting:

Hello,
I try this (in the place of DefaultLayers 6 8 10).
This work until I shade/unshade the gnome panel, after
this operation it seems that the panel forget the StaysPut Style.
Note also that it seems that the Layers of the shade/unshade 
button of the panel when the panel is shaded is stronger than 
the Layer of the panel when it is unshaded. 
I use gnome-core-1.0.8.
Olivier
--
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: Tue, 7 Sep 1999 13:08:13 +0200

> Sorry, this did not solve the problem.

Hm, I guess fvwm still allows the application to switch the layer,
even with StaysPut. I'll check this.

Bye

Dominik ^_^

---

From: Dominik Vogt <[email-masked]>
Date: Tue, 7 Sep 1999 13:56:12 +0200

> the Layer of the panel when it is unshaded. 

I get the impression that fvwm is not the right place to fix this.
Users are always annoyed by this 'clever' applications that think
they know better where the user wants them.  Fvwm is merely doing
what the panel tells it.  Of course we could write a style option
to disable the GNOME hints.  But the usability problem is the fault
of all these applications doing fancy tricks with layers.  I suggest
someone writes a bug report to the GNOME (and possibly KDE) folks
about this.

Bye

Dominik ^_^

---

From: "Eric Gillespie, Jr." <[email-masked]>
Date: Tue, 7 Sep 1999 11:18:44 -0500

On Tue, Sep 07, 1999 at 01:56:12PM +0200,
> someone writes a bug report to the GNOME (and possibly KDE) folks

I'm not so sure. The problem is very recent. I have been using CVS fvwm
for quite some time with no problems. Only when I updated to 2.3.8 did
this start.

---

From: Dominik Vogt <[email-masked]>
Date: Tue, 7 Sep 1999 18:57:52 +0200

> for quite some time with no problems. Only when I updated to 2.3.8 did

:-p

Of course I couldn't reproduce the problem here, but the panel I have
isn't up to date and doesn't have the options you mention.

Bye

Dominik ^_^

---

From: Dominik Vogt <[email-masked]>
Date: Thu, 9 Sep 1999 01:24:06 +0200

> 	works fine at the moment, but all windows are below the panel.

I can confirm that the layer handling code in fvwm wasn't bullet proof
when applications changed their own layer.  Technically the reason is
this:  Fvwm keeps a ring list of the window stacking order internally.
The stack ring is kept sorted by layer.  When a window changed its own
layer, this change didn't update the stack ring correctly (probably
caused by a bug in the latest transient handlich patch).  I have made
a temporary fix for the problem, but since I didn't see it myself I
need to know if the problem still occurs with the current CVS code.

Bye

Dominik ^_^

--
Dominik Vogt, [email-masked]
Reply-To: [email-masked]
--
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: "Eric Gillespie, Jr." <[email-masked]>
Date: Thu, 9 Sep 1999 11:02:34 -0500

On Thu, Sep 09, 1999 at 01:24:06AM +0200,
> need to know if the problem still occurs with the current CVS code.

Sorry, it didn't help. It still behaves exactly the same as before I
updated.