I have similar problems (posted on 19 Sept); the problem is that the
amount of shift is related to borderwidth, and is not easy to
reproduce. I have had the "greatest success" with some simple tk
activity, but have been unable to really locate the problem (though it
seems related to the "#define BW 1" in fvwm.h (2.0.45 and 2.0.46) and
the state of the XWindowChanges xwc object.
I have spent several hours in gdb and wish trying to track this down,
but get stopped trying to watch X events without freezing my machine.
(And then I get distracted by sleep, spouse, and bodily functions)
simplest demonstration (in Tcl/Tk):
$ wish
% wm geometry .
200x200+103+219
% wm geometry . +107+200
% wm geometry .
200x200+107+200
% winfo x .
106
% winfo y .
199
% wm geometry . +107+200
% winfo x .
200
% winfo x .
107
% exit
$
So where did the lost pixel go?? And why was it found after the
second
wm geometry . +107+200
which did NOT move the stuff displayed on the screen!
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 - 09:15:02 GMT