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.
bradym_at_cs.arizona.edu
>
> 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?
>
> bradym_at_cs.arizona.edu
>
--
To unsubscribe from the list, send "unsubscribe fvwm" in the body of a
message to majordomo_at_hpc.uh.edu.
To report problems, send mail to fvwm-owner_at_hpc.uh.edu.
Received on Wed Feb 07 1996 - 17:22:40 GMT