Subject: FvwmForm slow to close?

From: [email-masked] (Paul D. Smith)
Date: 29 Jun 1999 01:26:39 -0400

One thing I've noticed for a while is that FvwmForm takes a lot longer
to tear down the Form window than it used to.  I used to hit return or
quit or a button and it would _immediately_ go away.  Now it hangs
around for probably a second or two before disappearing; a noticeable
delay.

For example, I have a form to start xterms (who doesn't ? :).  Before
I'd hit return and bang, the form would vanish then the xterm would
appear.  Now the xterm comes up... then the form goes away.

Anyone else notice this/have any ideas what FvwmForm is doing with
itself now that it didn't before?

-- 
-------------------------------------------------------------------------------
 Paul D. Smith <[email-masked]>         Network Management Development
 "Please remain calm...I may be mad, but I am a professional." --Mad Scientist
-------------------------------------------------------------------------------
   These are my opinions---Nortel Networks takes no responsibility for them.
--
Visit the official FVWM web page at <URL:http://www.fvwm.org/>.
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: Michael Han <[email-masked]>
Date: Tue, 29 Jun 1999 00:22:02 -0700

Previously...
>itself now that it didn't before?

Now that you mention it, I'd noticed the same thing. I seem to recall
the extra-long close surfacing some time around 2.1.x, though for a
while I couldn't get my forms working at all... It's all a blur now.
I'm willing to peek at the code, though I suspect Dan knows this best
and can find it fastest.
-- 
[email-masked]                         http://www.best.com/~mikehan/
coffee achiever                              San Francisco, California
"If you lend me some money, it'll be my treat."
--
Visit the official FVWM web page at <URL:http://www.fvwm.org/>.
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: [email-masked] (Paul D. Smith)
Date: 29 Jun 1999 10:15:30 -0400

I was sure I didn't see it in 2.2, but perhaps I was mistaken, if the
reason Michael found is correct (from an email he sent to me):

> I imagine this behavior to be attributable to the following from
> DoCommand():
>
>     /* This is a temporary bug workaround for the pipe drainage problem */
> #if 1
>     SendText(Channel,"KillMe", ref);    /* let commands complete */
>     /* Note how the window is withdrawn, but execution continues until
>        the KillMe command catches up with this module...
>        Do something useful... */
>     sleep(1);                           /* don't use cpu */
> #else
>     exit(0);
> #endif

Ah, my old friend bug #4 :).

RE: Dan's note to this bug: I look at it as a "workaround" :).

IMO fvwm should be fixed to manage the pipes better so these kinds of
shenanigans aren't necessary.  Not the least problem is it makes fvwm
look pokey and unresponsive.

---

From: Dan Espen <[email-masked]>
Date: Tue, 29 Jun 1999 10:29:11 -0400

> look pokey and unresponsive.

Uhh, guys, slow down.  I've  been back in the  office 2 1/2 hours, and
just finished reading my mail and was about  to look into the problem,
and here is the answer...

I  guess I thought  the one second sleep  would be invisible, and with
the speed that my home system operates, it really was invisible.

The "solution" is to just remove the sleep.  As I will attempt to do
provided one of you doesn't beat me to it.

> -- 
>  Paul D. Smith <[email-masked]>         Network Management Developmen

--
Dan Espen
444 Hoes Lane  Room RRC 1C-214           E-mail: [email-masked]
Piscataway, NJ 08854                     Phone: (732) 699-5570
--
Visit the official FVWM web page at <URL:http://www.fvwm.org/>.
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: [email-masked] (Paul D. Smith)
Date: 29 Jun 1999 10:45:23 -0400

%% Dan Espen <[email-masked]> writes:

  de> I guess I thought the one second sleep would be invisible, and
  de> with the speed that my home system operates, it really was
  de> invisible.

  de> The "solution" is to just remove the sleep.  As I will attempt to
  de> do provided one of you doesn't beat me to it.

I guess I assumed the sleep() was there for a reason.

---

From: Dan Espen <[email-masked]>
Date: Tue, 29 Jun 1999 10:52:03 -0400

> look pokey and unresponsive.

I think the sleep command I introduced was just  some bad reasoning on
my part.   I'm not  against fixing bug  #4,  but using "killme"  works
pretty well.

---

From: Dan Espen <[email-masked]>
Date: Tue, 29 Jun 1999 11:08:38 -0400

> I guess I assumed the sleep() was there for a reason.

Well, there  is an XWithdrawWindow  just before this logic.  I thought
that  would make the window  disappear.  (It  doesn't  seem to.)  So I
reasoned that going to  sleep to give fvwm2  time  to turn  around the
"killme" command would be a good idea.

I'm a little  confused about the  XWithdrawWindow, but  looking back I
think going  on the the  piperead is just  as good  a way  of going to
sleep as the call to sleep.  (Probably the same system call anyway.)

---

From: Brad Giaccio <[email-masked]>
Date: Tue, 29 Jun 1999 11:30:33 -0400

> sleep as the call to sleep.  (Probably the same system call anyway.)

Paul, I'm grasping at straws here but you could try checking the return
value of XWithdrawWindow to see if the UnmapNotify succeded or not.  If
it didn't then fvwm has a problem with synthetic UnmapNotify's.

Brad

-- 
--- There are two kinds of knowledge, you either know the answer or
			you know where to find it
		      -Kane, Johnson, and anonymous
--
Visit the official FVWM web page at <URL:http://www.fvwm.org/>.
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: [email-masked] (Paul D. Smith)
Date: 29 Jun 1999 13:55:52 -0400

%% Brad Giaccio <[email-masked]> writes:

  bg> Paul, I'm grasping at straws here but you could try checking the
  bg> return value of XWithdrawWindow to see if the UnmapNotify succeded
  bg> or not.  If it didn't then fvwm has a problem with synthetic
  bg> UnmapNotify's.

It fails with an error code if 1 (BadRequest).

Maybe the parameters aren't correct or s'thing?

---

From: Brad Giaccio <[email-masked]>
Date: Wed, 30 Jun 1999 06:29:35 -0400

> Maybe the parameters aren't correct or s'thing?

Well that is a little odd, straight from the man page
     The XWithdrawWindow function unmaps the specified window and
     sends a synthetic UnmapNotify event to the root window of
     the specified screen.  Window managers may elect to receive
     this message and may treat it as a request to change the
     window's state to withdrawn.  When a window is in the with-
     drawn state, neither its normal nor its iconic representa-
     tions is visible.  It returns a nonzero status if the Unmap-
     Notify event is successfully sent; otherwise, it returns a
     zero status.

     XWithdrawWindow can generate a BadWindow error.

Its not supposed to generate BadRequest errors, just BadWindow my
guess is that fvwm is causing the BadRequest because it doesn't handle
synthetic UnMapNotifies properlly, i.e. making the window state withdrawn.

Brad