This really got my interest. This is not exactly something related
only to fvwm however. The wish example can be taken further to other
window managers. It seems the first time you specify the geometry the
geometry is given for the frame and then the actual window is slightly
moved for the borders. If you open X with an xterm as your window
manager (no borders), the geometry is the same the first time.
sun1464$ wish
% winfo x .
0
% winfo y .
0
% wm geometry .
200x200+0+0
% wm geometry . +107+200
% winfo x .
107
% winfo y .
200
% wm geometry .
200x200+107+200
I then started olwm in another xterm while leaving the wish up.
% winfo x .
112
% winfo y .
225
% wm geometry .
200x200+107+200
% wm geometry . +107+200
% winfo x .
107
% winfo y .
200
% wm geometry . +110+210
% winfo x .
115
% winfo y .
235
% wm geometry . +110+210
% winfo x .
110
% winfo y .
210
% wm geometry .
200x200+110+210
I haven't done any of the tracing through, so I couldn't tell you
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).
It is really interesting however.
-walter
ps. I did follow his example using fvwm first. :)
--
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:34:23 GMT