Subject: debug messages for growing windows problem

From: Dominik Vogt <[email-masked]>
Date: Sun, 13 Dec 1998 02:25:14 +0100

I've hacked lots of debug stuff into various modules to
track the growing windows problem (there's even a new
module called fvwmdebug.c with functions to print
the contents of various parts of an FvwmWindow).

To activate it you must configure with --enable-debug-msgs
and then edit config.h and add the line

#define DEBUG

(or do it any other way you like). You should compile
only the main module with these settings.

You will get rather lengthy output. Before you start
reproducing the bug please run FvwmIdent on the window
you suspect to grow. Terminate the X server immediately
when the window has grown. Try to shorten the output as
much as possible before posting the (gzip'ed!) file.

Thanks

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: Danek Duvall <[email-masked]>
Date: Sun, 13 Dec 1998 17:46:08 -0800

I'm not sure what of this is useful, but I've attached the output from the
debugging session.  The interesting window is the 600x201 one, which moves
from +0+0 (line 84) to +1+1 (line 471) to +2+2 (line 922).  The reason the
size changes is because a different image was loaded.  The first two images
are the same size.

I expected the Identify data to show up in the debug output, but here it
is, copied by hand (in a non-test fvwm):

Name:			xv 3.10a: misc/fb-021897.gf <unregistered>
Icon Name:		misc/fb-021897.gif
Class:			XVroot
Resource:		xv
Window ID:		0x4c00239
Desk:			0
Width:			600
Height:			201
X (current page):	1
Y (current page):	1
Boundary Width:		5
Sticky:			No
Ontop:			No
NoTitle:		No
Iconified:		No
Transient:		No
Gravity:		NorthWest
Geometry:		600x201+1+1
Focus Policy:		Passive
 - Input Field:		True
 - WM_TAKE_FOCUS:	Absent

Any of this useful?

Thanks,
Danek

---

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

On Sun, Dec 13, 1998 at 05:46:08PM -0800, [email-masked] wrote:
>...

Thanks. I don't know it it's useful, but we'll see. The Ident info
was just that I can find the relevant lines. I always had the
impression that this bug was a bit tricky to reproduce and in a
test session at home I got 3.5 MB debug output in 30 minutes.
I may have fixed this bug in the meantime (see some other posting).
Could you please try again with the current sources?

Bye

Dominik
-- 
Dominik Vogt, Hewlett-Packard GmbH, Dept. BVS
Herrenberger Str.130, 71034 Boeblingen, Germany
phone: 07031/14-4596, fax: 07031/14-3883, [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: Danek Duvall <[email-masked]>
Date: Mon, 14 Dec 1998 02:15:38 -0800

> Could you please try again with the current sources?

No such luck, sorry.  :-(

Time for bed now.

Danek

---

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

> is, copied by hand (in a non-test fvwm):

It was the same behaviour Tim noticed in some other posting.
I have fixed this one, but I am unsure if some other bug
now springs back into life.

Bye

Dominik

---

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

> now springs back into life.

I've changed FvwmWinList to grow properly.  It was using the module information
from fvwm to calculate it co-ordinates but the module information doesn't include
the borderwidth of the frame so it was wandering up and left by one when it had
an FvwmBorder style. It now queries the server to find its co-ordinates and does
it with an XGrab so it survives a recapture without wandering.

Cheers,
Tim.