Subject: FVWM: Wait comand behaviour changed

From: John Latham <[email-masked]>
Date: Mon, 12 Aug 2002 18:24:58 +0100

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

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

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

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? :-)

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

---

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

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

> Alas, in AnotherLevelUp I was using Wait in a multi-threaded way,

There is no multi threading in fvwm.

> waiting for

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.

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

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.

> to try abusing Wait in this way? :-)

I'll add something.

Bye

Dominik ^_^  ^_^

 --
Dominik Vogt, [email-masked]
Reply-To: [email-masked]
--
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].

---

From: Cameron Simpson <[email-masked]>
Date: Tue, 13 Aug 2002 10:32:41 +1000

On 23:21 12 Aug 2002, Dominik Vogt <[email-masked]> wrote:
| 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.''
[...]
| > 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.

Hmm. But more than one active Wait is not an insane idea.

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

On this kind of topic: what about a FvwmButtons Swallow whose client
never appears? I'd imagine this is unrelated to FVWM itself and that the
module is simply monitoring a stream of events from FVWM, or does the
module get to preempty something off FVWM's event queue to do a swallow?

Why do I ask? I swallow a wmflame in my button, but not on a VNC desktop
(because it means constant VNC traffic, which I explcitly don't want).
Now, instead of being smart and using piperead to conditionally generate
the swallowing button, I always generate the button but conditionally
fire up the wmflame.

Is this likely to cause me trouble? It seems to work ok so far.
-- 
Cameron Simpson, DoD#743        [email-masked]    http://www.zip.com.au/~cs/

The Web site you seek
cannot be located but
endless others exist
- Haiku Error Messages http://www.salonmagazine.com/21st/chal/1998/02/10chal2.html

---

From: Dominik Vogt <[email-masked]>
Date: Tue, 13 Aug 2002 02:56:42 +0200

> Hmm. But more than one active Wait is not an insane idea.

"Wait" works well only for windows that do appear do it fast.  Any
other use is asking for trouble.

> module get to preempty something off FVWM's event queue to do a swallow?

FvwmButtons just looks for a matching new window and otherwise
operates normally.  But there is one important differene.
FvwmButtons doesn't care when the window appears, but with the
"Wait" command you explicitly ask not to continue executing the
function that triggered it.  That is exactly what it is good for:
to not process any commands while the Wait is active.

> Is this likely to cause me trouble?

It's safe to do that.

> It seems to work ok so far.

Bye

Dominik ^_^  ^_^