Thanks for the followup, Walter.
> how this should be coded. I am guessing that the window manager
> somehow refigures the geometry for the window and this is what is
> used when you call the winfo x and winfo y, where the actual
> geometry shown when you say wm geometry . gives that X thinks the
> window is, and that should be what is parsed to create a structure
> to use for changing the geometry (not the winfo x and y).
This is correct. And it is true that each window manager is supposed
to keep track of where each window is within its borders, as well as
where the borders are within the parent window, and report the
appropriate ones to the children.
So far, though, fvwm is the only one I have found where there are
three distinct results that I can get. (my previous examples did not
show the third result; that is at home awaiting further
hammer-and-tong-ing). What I see is (relative to the location which I
specify) -1 pixel in the x and y directions, -borderwidth pixels in
the x direction and -(titlebarheight+borderwidth) in the y direction,
or the "correct" (i.e. +/- 0 pixels) number.
Donald.
--
Visit the official FVWM web page at <URL:http://www.hpc.uh.edu/fvwm/>.
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 Tue Nov 04 1997 - 10:42:19 GMT