Subject: Re: FVWM: Wait comand behaviour changed

From: John Latham <[email-masked]>
Date: Tue, 20 Aug 2002 16:08:34 +0100

> From: Dominik Vogt <[email-masked]>
> Date: Mon, 12 Aug 2002 23:21:38 +0200

> On Mon, Aug 12, 2002 at 06:24:58PM +0100, John Latham wrote:
> > This is not actually an undocumented feature change, but it is understated!
> > :-)
> > 
> > Fvwm 2.2.4 man page says: ``Fvwm remains fully functional during a wait.''
> > 
> > Fvwm 2.4.8 man page says ``Fvwm remains partially functional during a wait.''

> It's just a better description of what actually happens.  The Wait
> command itself was not changed in any relevant way.

> > I spotted the one word difference after a few hours tracking down the cause of
> > a very strange behaviour. Presumeably, you have optimised away some threads
> > that had a memory/CPU overhead, and perhaps never imagined anybody would be
> > using Wait in a clever (=stupid!) way.
> > 
> > Alas, in AnotherLevelUp I was using Wait in a multi-threaded way,

> There is no multi threading in fvwm.

> > waiting for
> > an effect from a form which prompts the user to save his/her current
> > preferences, if they have been changed since last saved; when he/she asks for
> > a new set of preferences to be loaded. So we had a Wait active at the same
> > time as a form that needed user interaction. In 2.4 this does not work as all
> > the window events seem to be disabled during a Wait, all mouse clicks act on
> > the root window only.

> Event processing continues as usual.  The modules can receive and
> send data to and from fvwm, but fvwm ignores all module input
> until the wait finishes.  As this was the same in 2.2.x, I'm not
> sure what was changed.  In general: Wait + using modules = bad.

This was indeed a Red Herring. I now understand why this stopped working! It's
that BusyCursor thing yet again: during the Wait, FVWM was holding the mouse,
so the user could not click on the FvwmForm buttons, which were the trigger
for ending the Wait. And I had not set BusyCursor Wait on, sugesting that FVWM
always grabs the mouse for a Wait too, regardless of BusyCursor Wait on/off.

The multi threading `feel' I had was coming from the FvwmForm process running
in parallel to FVWM, so one could say the `whole thing' is multi threaded, but
the mouse grabs now make the UI single threaded.

> > It probably serves me right! I have rewritten it to work in a different, and
> > single threaded, way.

> Good idea.  TH Wait command is really just meant to wait for a
> window that appears quickly.  Any other use is asking for trouble.
> You can easily achieve the same benefits with FvwmEvent, but
> without the bad side effects.

My new approach is much more reliable anyway. I seem to remember being unhappy
with the old approach, but needed to do it that way because I didn't realise
one could generate FvwmForm configurations dynamically (e.g. PipeRead) at the
time I first wrote it.

> > Is it worth writing some hints in the man page indicating what sort of things
> > do not work during a Wait -- or am I likely to be the only person daft enough
> > to try abusing Wait in this way? :-)

> I'll add something.

Thank you.

BTW, I have just spotted another ``fully functional'' phrase that you might
like to edit, at least it is still present in the 2.5.2 man page, in the
BusyCursor section.

> Bye

> Dominik ^_^  ^_^

Best wishes, John Latham
--
Visit the official FVWM web page at <URL: http://www.fvwm.org/>.
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].