Subject: FVWM: FvwmWinList is shifting left on me

From: "Sullivan N. Beck" <[email-masked]>
Date: Tue, 4 Nov 1997 09:42:15 -0500 (EST)

I just installed the newest (2.0.46) version of fvwm and overall I'm
pleased with it.  It fixes a couple of problems that I had before, but
it introduces a new bug.

I run the FvwmWinList module and the window list is not touching any of the
desktop borders (i.e. it's right in the middle of the screen).  Every time
an item is added or removed from the list (i.e. every time a new window is
created or a window is destroyed), the WinList shifts left one or two pixels.
After a while, the WinList is overlapping other windows.  Kind of annoying.

If there is a fix for this, could you tell me where to find it.

Thanks much

Sullivan Beck ([email-masked])
--
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: [email-masked] (A.J.vanWerven)
Date: Tue, 4 Nov 1997 15:49:40 +0100 (MET)

> If there is a fix for this, could you tell me where to find it.

If you want it to have a fixed size, try having it swallowed by some button.

CIAO di Al Grandi.

--------------------------------------------------------------------------

Beam me up Scotty, this planet sucks !

A. van Werven
Dept. of Physics, Leiden University
Huygens Laboratory, Leiden, Holland
Phone: +31 6 54212683
E-mail: [email-masked]
URL: http://www.wi.leidenuniv.nl/~avwerven

---

From: William Denton <[email-masked]>
Date: Tue, 4 Nov 1997 09:51:52 -0500 (EST)

On Tue, 4 Nov 1997, Sullivan N. Beck wrote:

: I run the FvwmWinList module and the window list is not touching any of the
: desktop borders (i.e. it's right in the middle of the screen).  Every time
: an item is added or removed from the list (i.e. every time a new window is
: created or a window is destroyed), the WinList shifts left one or two pixels.
: After a while, the WinList is overlapping other windows.  Kind of annoying.

I had this problem too, and IIRC I fixed it by setting

*FvwmWinListGeometry +0+0

instead of something with a 1 in it.  All my FvwmWinList settings are
at http://www./vex.net/~buff/linux.html, and you can compare yours to
mine.

Bill
-- 
William Denton | Toronto, Canada | http://www.vex.net/~buff/ | Caveat lector.
  "It is better to incur a mild rebuke than to perform an onerous task."
                                   -- "Uncle" Oswald Hendryks Cornelius

---

From: "Donald H. Locker" <[email-masked]>
Date: Tue, 4 Nov 1997 10:10:59 -0500

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.

---

From: "Donald H. Locker" <[email-masked]>
Date: Tue, 4 Nov 1997 10:23:50 -0500

Oops.

Forgot to mention that things move because many of the progs that I've
seen do the equivalent of the winfo x and winfo y to get current
coordinates while building a changes struct to pass to the wm.  Of
course, if wm has a different geometry, then a move "to the same
place" results in [at least] a one pixel shift left and up.  (Because
if they really were the same, the wm ignores the new location request,
but processes the rest of the Changes struct, which is what it is
supposed to do.)

This is most irritating in T.A.Phelps' tkman and Module FvwmIconMan
(which I would dearly like to change from

*FvwmIconMan*1*managergeometry		1x15-388-2

to

*FvwmIconMan*1*managergeometry		0x0-388-2

but it wanders)

Donald.

---

From: Walter Truitt <[email-masked]>
Date: Tue, 04 Nov 1997 10:33:01 -0600

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.  :)

---

From: "Donald H. Locker" <[email-masked]>
Date: Tue, 4 Nov 1997 11:38:45 -0500

Thanks for the followup, Walter.

> 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.

---

From: Kai Grossjohann <[email-masked]>
Date: 04 Nov 1997 18:02:39 +0100

>>>>> On Tue, 4 Nov 1997, Sullivan N Beck said:

  Sullivan> I run the FvwmWinList module and the window list is not
  Sullivan> touching any of the desktop borders (i.e. it's right in
  Sullivan> the middle of the screen).  Every time an item is added or
  Sullivan> removed from the list (i.e. every time a new window is
  Sullivan> created or a window is destroyed), the WinList shifts left
  Sullivan> one or two pixels.  After a while, the WinList is
  Sullivan> overlapping other windows.  Kind of annoying.

Try FvwmIconMan, which doesn't have the bug and is much better IMHO.

kai
-- 
~/.signature: No such file or directory

---

From: Brady Montz <[email-masked]>
Date: 04 Nov 1997 09:44:45 -0700

> but processes the rest of the Changes struct, which is what it is

Correct. There are ways you might be able to do it, but only if X had
semaphores. Basically you have two programs (the window manager and the
application) concurrently reading and writing a shared piece of data (the
window geometry), so there's no end to the possible race conditions. Not
good. I know of no way to make a window grow upward or leftward safely in
X. I've been completely unable to get anyone to tell me a way either. 

> *FvwmIconMan*1*managergeometry		0x0-388-2

I haven't seen FvwmIconMan wandering for some time, but I avoid the upward and
leftword growing modes. A managergeometry of 0x0 isn't even legal, and causes
FvwmIconMan to give an error message and exit. Could you elaborate?

-- 
 Brady Montz
 [email-masked]