Kai Grossjohann <grossjohann_at_charly.informatik.uni-dortmund.de> writes:
>
> This doesn't directly answer your question, but coming from ctwm
> myself, I'm now a happy user of FvwmIconMan which does (almost)
> everything the TWM icon manager does, and more.
>
> FvwmIconMan doesn't wander off for me...
>
> kai
> --
> Signature? What signature?
In the interest of the truth, FvwmIconMan can occasionally wander as well. In
the next version to be released, I think I've finally got it fixed, but I've
thought that many times before. This is such a major annoyance to me, I have
to vent. I don't know nearly as much about X as there is to know, so if I am
in error, please correct me!
I can't speak for why FvwmWinList is wandering, but it may be for the same
reason as FvwmIconMan. Essentially, you have two programs which can modify a
shared piece of information (the programs being fvwm, and FvwmIconMan, and the
shared information is the (x, y) coordinates of the window). Since X supplies
no synchronization primatives, if either program decides to modify this info in
a nonatmoic fashion, you get a race condition. In this case, if FvwmIconMan is
started with a negative y coordinate (like -0), it tries to grow its window
upwards. There is no atomic X function to do this, so it has to be done in two
steps: 1. read the current (x, y) coords then 2. set the new (x, y) coords.
Step 1 can either be done implicitely by listening for ConfigureNotify
events, or actively by quering the X server right before doing the
resize. Either way, since there is no "resize upwards function" (as far as I
know), there will be some period of time between those two steps, and if,
during that period, the window gets moved, your window will start wandering.
The most obvious race condition is if you move the window via fvwm while it's
trying to resize itself. But you also have a problem where the application
moves itself a bunch of times in succession, because then the X server may
process some of these move requests between the time the app "reads" the (x,
y) coords, and when it "writes" it.
A very sticky problem. In the FvwmIconMan case, one which would be easily
avoided if X provided (and I knew about it) one of the following:
1. semaphores on windows.
2. a XMoveWindow or XMoveResizeWindow function that would do a relative move
(like move left 10 pixels).
3. a foolproof way to look at a ConfigureNotify event and tell from which
client that event originated.
I'm wary of using XGrabServer, since I've caused some nasty X lockups with
that.
--
Brady Montz
bradym_at_cs.arizona.edu
--
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 Jan 28 1997 - 18:29:59 GMT