> 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
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.
--
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 Thu Feb 08 1996 - 03:17:30 GMT