Subject: another possible cause for growing windows

From: Dominik Vogt <[email-masked]>
Date: Sun, 13 Dec 1998 13:39:37 +0100

I've found another possible reason why windows might
have been growing, again in resize.c (ConstarinSize):

There were static globals xmotion and ymotion used for
some internal calculation, but again these were not
set when ConstrainSize was called from outside resize.c.
I have removed all globals from the file to prvent these
side effects in the future, but I'm not sure if I did
the right thing with xmotion/ymotion: I made them
parameters to ConstrainSize and set them to zero in the
calls from other modules (add_window.c, events.c and
buitins.c).

Tim, since you seem to know what's going on in
ConstrainSize, could you please have a look at his
(everybody else is welcome too, of course)?

Bye

Dominik
-- 
Dominik Vogt, [email-masked]
Reply-To: [email-masked]

--
Visit the official FVWM web page at <URL:http://www.hpc.uh.edu/fvwm/>.
To unsubscribe from the list, send "unsubscribe fvwm-workers" in the
body of a message to [email-masked].
To report problems, send mail to [email-masked].

---

From: Tim Phipps <[email-masked]>
Date: Mon, 14 Dec 1998 13:55:32 +0000

> (everybody else is welcome too, of course)?

Well, I've had a look and now I'm horribly confused. I can get xv to
wander down and right if I have FvwmBorders on.  When xv changes picture a
configure request is received by Fvwm.  Fvwm looks at the xv request
co-ordinates and it's frame and thinks the window has moved.  You can fix
this by changing the #define BW 1 in fvwm.h to 0 but then FvwmBorder
windows look just like MWMBorder.  I've got completely confused by the way
the code treats win->frame_x.  I think I may have removed a win->bw from
some calculation in the past.

Sorry I can't come up with a fix, but I'm dazed and confused at the
moment.
Tim.

---

From: Dominik Vogt <[email-masked]>
Date: Mon, 14 Dec 1998 23:01:21 +0100

> some calculation in the past.

Yup. That is exactly what happened. Between 2.0.46 and 2.1.x
some lines in events.c (HandleConfigureRequest) had been changed:

from

  if (cre->value_mask & CWX)
    x = cre->x - Tmp_win->boundary_width - Tmp_win->bw;
  if (cre->value_mask & CWY)
    y = cre->y - Tmp_win->boundary_width - Tmp_win->title_height - Tmp_win->bw;

to

  if (cre->value_mask & CWX)
    x = cre->x - Tmp_win->boundary_width;
  if (cre->value_mask & CWY)
    y = cre->y - Tmp_win->boundary_width - Tmp_win->title_height;

I vaguely remember you noticed this before. Why was this changed?
Did it have something to do with the wandering winlist?

I backed that change out and xv does not wander anymore.

Bye

Dominik

---

From: Tim Phipps <[email-masked]>
Date: Tue, 15 Dec 1998 11:29:35 +0000

> I backed that change out and xv does not wander anymore.

I think this is the right thing to do.  I did the previous change to stop
FvwmWinList wandering.  I'll fix FvwmWinList properly this time.

Fvwm seems a bit schizo about its frame co-ordinates.  With FvwmBorders the
co-ordinates used in XLib calls are 1 greater than is drawn on the screen due to
the
frame window having a borderwidth of one.  Fvwm and FvwmWinList are not being
consistent when using the co-ordinates and frame width to calculate where to move
to when it grows.

Cheers,
Tim.