Subject: FVWM: Re: tricky problem with fvwm reparenting

From: Brady Montz <[email-masked]>
Date: Wed, 7 Feb 1996 16:22:32 -0700 (MST)

I no longer need an answer to this question, as I've gone back to the
original method I used: just wait for fvwm to tell the program what its
location is. This seems to work, but I don't remember why I stopped doing
it that way. 

For those who are curious about such things, I tried the obvious method
arising from what I described below, just call XGetGeometry on the frame
window and then compute the new location, and I believe I ended up with a race
condition if I was moving between pages while the manager was resizing itself
(which is often since it always resizes itself when you change pages), and it
didn't work.

[email-masked]

> 
> 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].