> From: Dominik Vogt <dominik.vogt_at_gmx.de>
> 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 majordomo_at_fvwm.org.
To report problems, send mail to fvwm-owner_at_fvwm.org.
Received on Tue Aug 20 2002 - 10:09:55 BST