Subject: Growing windows (Motif apps?)

From: Bob Woodside <[email-masked]>
Date: Tue, 24 Nov 1998 22:08:10 -0500 (EST)

Again, I'm splitting this thread into discussions of the
indovidual problems, with shorter titles.

	Giuseppe, have you noticed the "growing window" problem
with any non-Motif applications? I've only seen it happen with
Motif apps, but I may be barking up the wrong tree.

	I have not been able to reproduce it since installing
the latest CVS build (this evening, 24/11). But it's only been
a couple of hours, and most of the time since I've been occupied
with early Thanksgiving dinner preparations. And, I've thought
it had gone away before, only to see it reappear.

	Nevertheless, I would be curious to know whether you still
see the problem if you update once more from the latest CVS sources.

- Bob

--
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: Bob Woodside <[email-masked]>
Date: Wed, 25 Nov 1998 08:08:30 -0500 (EST)

Bob Woodside <[email-masked]> wrote:
> the latest CVS build (this evening, 24/11)....

	Just a quick followup: after running for a bit longer,
I see that the problem is still very much there....

- Bob

---

From: Giuseppe Della Ricca <[email-masked]>
Date: Wed, 25 Nov 1998 14:07:52 +0100 (MET)

> Motif apps, but I may be barking up the wrong tree.
I've seen it with Netscape (I know, I know ...) and with xload

(I don't know if it is compiled against Motif or not)

> see the problem if you update once more from the latest CVS sources.

Yes, still there with:
fvwm2 -version
[FVWM][main]:  Fvwm Version 2.1.3 compiled on Nov 25 1998 at 11:15:53
(recompiled just after "cvs-update")

---

From: Brad Giaccio <[email-masked]>
Date: Wed, 25 Nov 1998 09:28:10 -0500 (EST)

I also see it with xload ,xclock, xcpustate, netscape, tkgoodstuff,
FvwmButtons.

Brad

-- 
--- There are two kinds of knowledge, you either know the answer or
			you know where to find it
		      -Kane, Johnson, and anonymous

---

From: Giuseppe Della Ricca <[email-masked]>
Date: Wed, 25 Nov 1998 22:59:21 +0100 (MET)

Hi !

I've the following lines in my .fvwm2rc (I've added the newlines and
the "\"):

*FvwmButtons(     Swallow(Close,Kill,NoOld) "XBiff-BB" \
 "Exec exec xbiff -geometry -1500-1500 -bg grey80 -title XBiff-BB",
 Title "Pine", \
 Action (Mouse 1) `Exec "Pine" exec xterm +sb -title Pine -n Pine -e pine -d 0`)

*FvwmButtons(     Swallow(Close,Kill,NoUse) "XLoad-BB" \
 "Exec exec xload -geometry -1500-1500 -bg grey80 -nolabel -title XLoad-BB")

*FvwmButtons(5x1, Swallow(Close,Kill,NoUse) "FvwmPager" "FvwmPager 0 4")

At startup everything is fine. If I kill FvwmButtons, xload and FvwmPager
are killed, but xbiff is in the process list. 

Then, after restarting FvwmButtons, FvwmPager is restarted and swallowed,
xload is restarted and swallowed, while a *new* xbiff is started and
swallowed: the old one remains alive (I've checked, it still beeps when I
receive mails: I've found this problem because after restarting several
times the new mail notification was REALLY noisy !).
 
After closing FvwmButtons, the output of: "xlswins | grep iff" is empty,
but the output of: "ps -u dellaric | grep iff" is not !

I can solve all this just applying some code that is already in 
FvwmButtons.c, i.e.

diff -c FvwmButtons.c FvwmButtons.c.orig
*** FvwmButtons.c       Wed Nov 25 22:16:52 1998
--- FvwmButtons.c.orig  Tue Nov 24 16:00:52 1998
***************
*** 179,185 ****
  **/
  void DeadPipe(int whatever)
  {
! #if 1 /* can't do all this in a signal handler, so just exit */
    button_info *b,*ub=UberButton;
    int button=-1;
  
--- 179,185 ----
  **/
  void DeadPipe(int whatever)
  {
! #if 0 /* can't do all this in a signal handler, so just exit */
    button_info *b,*ub=UberButton;
    int button=-1;

It seems to me that, at least in this particular case (xbiff refusing to
die), this approach works. What's wrong with the code in DeadPipe ?

cheers,
Giuseppe.

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

 Giuseppe Della Ricca.  INFN - Trieste
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

---

From: Tim Phipps <[email-masked]>
Date: Thu, 26 Nov 1998 09:42:43 +0000

> *FvwmButtons(5x1, Swallow(Close,Kill,NoUse) "FvwmPager" "FvwmPager 0 4")

The NoUse doesn't exist but that's not your problem.  If xbiff is not
dying and you want it to be reused when you restart FvwmButtons you
should use the UseOld option.  The NoOld option tells FvwmButtons to
ignore any existing windows called XBiff-BB and to start a new one to
swallow.

> I can solve all this just applying some code that is already in

This is the cause of your problems.  It's a generic design fault in lots
of Fvwm modules.  The DeadPipe function is used as the signal handler
for every signal that FvwmButtons is ever likely to receive but the
functions is designed to be used only when the module interface pipes to
Fvwm are closed.  The signal handlers for the other signals should
probably do other things.  The reason that the clever stuff in
DeadPipe() is commented out is that some of the signals can happen in
the middle of Xlib function calls.  Xlib is not re-entrant or signal
safe and so you shouldn't call Xlib from a signal handler unless you
know that you're not in the middle of an Xlib call and that XFlush() has
been called (maybe even XSync()?).
What a signal handler should do is to set a global flag and return. The
flag should be examined frequently and the clever DeadPipe() called when
it is safe to do so.

At the moment it looks like the Kill/NoKill flag is useless. What
happens is that when the FvwmButtons window is destroyed the swallowed
windows get sent events (anybody know what?) and some programs quit
(xload, pager) and others don't. A workaround for you is to use the
UseOld flag for XBiff.

The reason for the commenting out is that some modules wouldn't die when
the X-server exited and would go into an endless loop.  Most modules
don't run other programs and so the correct behaviour is to just die on
any signal.  FvwmButtons is one exception and maybe it should be fixed. 
At the moment it's not as broken as it was.

Cheers,
Tim.

---

From: Dominik Vogt <[email-masked]>
Date: Thu, 26 Nov 1998 12:59:26 +0100

> At the moment it's not as broken as it was.

Last time this came up you had some suggestion how to workaround
that (checking which pipe has closed, I think). Can you give me
a hint how to do this (or create a patch? ;-) ).

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