Subject: Fix for KFM override_redirect windows

From: Bob Woodside <[email-masked]>
Date: Tue, 14 Sep 1999 22:15:07 -0400

After the third rewrite from scratch, I think I have this just about
right. I'm just about ready to commit it, but it's raised a couple of
issues we may want to discuss.

	The main one is that the current RaiseLower handling doesn't work
properly with the new BugOpts RaiseOverUnmanaged. Does anyone remember
what the reason was for the overlap check? If you have a window that's
below the KFM icons, but doesn't happen to overlap any FVWM-managed
windows, it is assumed to be at the top of its layer and gets lowered
instead of raised. To get RaiseLower to work properly in this situation,
I had to change the RaiseLower on-top test to a very simple check for
whether the next higher window is in the same layer as the target. Can
someone explain to me why it shouldn't be this way?

	The second one is that I occasionally observe quirks with the
RaiseOverNativeWindows handling. These may be due to buggy apps, I don't
know, but with RaiseOverNativeWindows enabled, a couple of apps (moxfm
and nedit are the ones I can consistently trigger it with) will pop up
transients with no window in them, just a little bit of FVWM frame.
(That's just a visual description, I haven't tried to analyze them to
see just what's happening.) However, with the new RaiseOverUnmanaged
code running, this doesn't happen. Now, RaiseOverUnmanaged happens
before the raise hack, so there are no longer any unmanaged windows
above the target FVWM window: the raise hack only raises FVWM windows.

	This leads me to question whether we should be trying to raise
override_redirect windows, or whether they should be left to their own
devices. I understand that not trying to raise them loses some of the
benefits (for popups and the Pager's ballons) that led Matthias to the
GSOR (Great StackingOrder Rewrite) in the first place. However, one
could argue that all these special case hacks are apt to be imperfect
attempts to deal as best we can with ill-behaved apps, so trade-offs
have to be accepted. The question is which trade we want to make.

Cheers,
Bob
--
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: Wed, 15 Sep 1999 15:06:02 +0200

> someone explain to me why it shouldn't be this way?

Imagine you have a window that is fully visible and obscures several
other windows you want to see. I would expect thast RaiseLower lowers
the window in this situation. Otherwise you would have to click twice
before something happens.

> have to be accepted. The question is which trade we want to make.

If someone complains about fvwm because of these buggy apps, I want
to be able to say: "Well, it's really the fault of your application,
but if you can't live with it, there's an option in fvwm that can
help you, although it is not perfect..."

Of course we could easily say that the problem is 100% the fault of
KFM, but in the end that would mean that nobody would use fvwm with
the current KDE version.

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: Bob Woodside <[email-masked]>
Date: Wed, 15 Sep 1999 22:22:44 -0400

Dominik Vogt wrote:
> >                         ...the current RaiseLower handling doesn't work

	Hmmm...I would expect to use the Lower function instead of RaiseLower
in this situation, if I wanted a single-click operation. To me this
seems to be adding too much cleverness to a function whose real purpose
is simply toggling between top and bottom. I really much prefer the
simpler interpretation of RaiseLower, but I'd like to hear others'
opinions.

	In any case, it's definitely broken when you're trying to raise above
override_redirects. I don't fancy having to tell a user "Drag that
window till it overlaps some other, non-override_redirect window, and
RaiseLower will raise it over KFM...um, maybe." Now, I can put special
handling in RaiseLower for the RaiseOverUnmanaged case, but I'm not
overly fond of the idea. Any other opinions?

> KFM, but in the end that would mean that nobody would use fvwm with

	[Gack!] That won't do.

	We're certainly in agreement on principle here. I'm just not sure
whether to take this answer as a yea or a nay. But, then, I probably
didn't make my original statement into a clear yea or nay question. I'm
suggesting that we consider removing the raising of override_redirect
windows (or, more generally, all unmanaged windows, whether o_r or not)
from the RaiseOverNativeWindows hack. Does anyone have strong feelings
on this one...particularly feelings based on experience with Exceed and
its ilk (which I don't have).

	I'm beginning to suspect (though I won't have much chance to look into
it for a couple of days) that there are more things than simply
override_redirects to consider, based on the problem I see with moxfm
and nedit transients. I'm wondering if there are race conditions such
that there are embryonic windows, if you will, as yet unrealized
non-override_redirect windows whose existence the X server reports to
us, but which are not yet managed by us (not yet in the chain); if so,
the RaiseOverNativeWindows code blithely attempts to raise them, which
may not be a Good Thing.

	In any case, the conjunction of my RaiseOverUnmanaged code with the
RaiseOverNativeWindows code shows the problem not occurring when the
only windows we explicitly raise are those for which we have an
FvwmWindow in the chain. Opinions...?

Cheers,
Bob

---

From: Olivier Chapuis <[email-masked]>
Date: Fri, 17 Sep 1999 12:46:09 +0200

> KFM, but in the end that would mean that nobody would use fvwm with

Hello,
Probably every body know that but we can answer this to the user:

<An answer to a faq>
1. Create a director ~/.kfmbug
2. Move the contenent of ~/Desktop to this directoy
3. Edite the [path] section of ~/.kde/share/config/kfmrc
so that it become some thing like this:

[Paths]
Trash=$HOME/.kfmbug/Trash
cdrom=$HOME/.kfmbug/Autostart
Templates=$HOME/.kfmbug/Templates
Autostart=$HOME/.kfmbug/Autostart

Then, You do not have any more the kfm icons on your desk.
If you can't live without these icons  use your imagination
and FvwmButtons, fvwm menu ...etc to simulate these icons !
</An answer to a faq>

Olivier

---

From: Dominik Vogt <[email-masked]>
Date: Thu, 16 Sep 1999 21:35:20 +0200

> overly fond of the idea. Any other opinions?

Hm, why does RaiseLower have something to do with with the override
redirect hack? Can't we simply ignore such windows when it comes to
raising/lowering fvwm managed windows?

> its ilk (which I don't have).

Then I don't understand your question. If you're asking if we should
remove the exceed hack I think, yes, there are people who won't like
this. Or do you want to move the code somewhere else? In this case I
don't understand why you ask instead of simply doing it. Or do you
have something else in mind?

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: Dominik Vogt <[email-masked]>
Date: Sun, 19 Sep 1999 14:50:51 +0200

> To report problems, send mail to [email-masked]

Uh, I guess a user of KFM actually *wants* those icons or he
wouldn't use KFM.

Bye

Dominik ^_^

---

From: Bob Woodside <[email-masked]>
Date: Sun, 19 Sep 1999 14:41:53 -0400

Dominik Vogt wrote:
> redirect hack?

	Because RaiseLower is currently biased toward lowering a window rather
than raising it, thanks to the overlap check. If a regular window is
below an override_redirect, but is not overlapped by another regular
window, RaiseLower will never raise it above the override_redirects,
because it will never raise it, period: it will always choose to *lower*
it, and the raise hack never gets a chance.

> Can't we simply ignore such windows when it comes to raising/lowering
> fvwm managed windows?

	Ignoring them is our normal handling; that's why the hack is needed in
the first place, so we can detect when one is above our target window
and raise above it.

	This is just one of several problems I'm finding with RaiseLower (I
mentioned another yesterday ("ClickToFocusDoesn'tRaise...Does"). Now,
somebody went to a good deal of trouble to add the overlap logic, so I
have to believe it was because he found it useful; and probably many
others do too. But I find it just the opposite. I'm beginning to think
we need two different styles (please don't hit me...no...put down that
awk!)...something like SimpleRaiseLower (it's either on top or it isn't)
and CleverRaiseLower (with overlap checking). Well, ok, Simple would
need to take the new transient styles into account.

> have something else in mind?

	I was asking because I don't have any experience with using FVWM under
Exceed, and I was looking for feedback from the original author
(Matthias?) or anyone else who uses Exceed. From the underwhelming
response, I gather that most of the developers are fortunate enough not
to have to use it. I'll just make the change and see who squawks, then.

	The change I was suggesting is neither moving nor removing the code.
The code now attempts to raise everything, override_redirects and all;
what I proposed was that the Exceed hack only raise FVWM-managed
windows, and leave the others on their own. In effect this is the result
you would get now if you used both RaiseOverNativeWindows and
RaiseOverUnmanaged, since by the time we hit the Exceed hack all our
windows will have already been raised above the overide_redirects.

Cheers,
Bob