Subject: FVWM: tricky problem with fvwm reparenting

From: Brady Montz <[email-masked]>
Date: Wed, 7 Feb 1996 14:08:51 -0700 (MST)

I'm just about to release FvwmIconMan 0.3, but I have one last bug that I just
can't squish. This problem has actually been around since forever, and I
want to get rid of it for once and all.

For those who have't used it, for this problem just think of it like WinList.

When the user specifies a geometry with a negative y coordinate, then the
manager window should grow upwards. To do this, I need to move the window,
then resize it (I actually use XMoveResizeWindow). To do this, I need to
know what the global location of my window is.

Looking at the fvwm source code, it appears that fvwm puts two layers of
parents on top of all managed windows, one immediately containing the window, 
and then the frame window. Is this correct, and if it's correct, is it
consistently correct? Cause then I'll just go back to the grandfather window
to figure out my global location. If not, then are there any suggestions?

[email-masked]
--
To unsubscribe from the list, send "unsubscribe fvwm" in the body of a
message to [email-masked].
To report problems, send mail to [email-masked].

---

From: [email-masked]
Date: Thu, 8 Feb 96 09:19:31 +0000

> to figure out my global location. If not, then are there any
suggestions?

The standard way of dealing with this independantly of window manager
is to call XQueryTree repeatedly until you get to the root window.
(This is according to ICCCM I believe).
There are two problems with this though.
    1) It is very inefficient because it requires a round trip to the
X server for each level of window above the shell widget.
    2) It doesn't necessarily work for situations where the root
window has been superceded.  Is it vroot that does this ?

The solution to (1) is to only do the XQueryTree process when you get
the XReparentEvent, and store the top-most window id somewhere.

The solution to (2) is to include vroot.h (is that it ?) which will
allow you to work out the id of the pseudo-root.  The problem is, what
if there are multiple implementations of this pseudo-root concept ?

Hope that helps,
    Jonathan.