Subject: FVWM: Wandering WinList

From: Graham Gough <[email-masked]>
Date: Tue, 28 Jan 97 12:49:51 GMT

I have recently switched to fvwm2.0.43 (on SunOS4.1 and Linux) after
many years of using twm/ctwm and am very happy with the move, thanks
to all fvwm2 developers.

Now for the problem; I have a WinList permanently displayed

*FvwmWinListUseSkipList
*FvwmWinListGeometry -15+90
*FvwmWinListUseIconNames
*FvwmWinListMaxWidth 110

but as items are added and deleted to it it wanders off in a South
Easterly direction. Is there a known fix for this problem?

Graham
--
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 [email-masked].
To report problems, send mail to [email-masked].

---

From: Kai Grossjohann <[email-masked]>
Date: 28 Jan 1997 22:24:20 +0100

>>>>> Graham Gough writes:

  Graham> I have recently switched to fvwm2.0.43 (on SunOS4.1 and
  Graham> Linux) after many years of using twm/ctwm and am very happy
  Graham> with the move, thanks to all fvwm2 developers.

  Graham> Now for the problem; I have a WinList permanently displayed
  Graham> [...]

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?

---

From: Allen Brady Montz <[email-masked]>
Date: 28 Jan 1997 17:29:41 -0700

> FvwmIconMan doesn't wander off for me...

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
 [email-masked]