Subject: module_interface.c (executeModuleSync)

From: Olivier Chapuis <[email-masked]>
Date: Wed, 13 Oct 1999 09:43:43 +0200

Hello,

In module_interface.c (executeModuleSync) there is no
return after "KillModule(pipe_slot, 10);" this seems quite
strange (sorry if a misunderstand something).

Also it will be good, I think, if we can Escape from
this function as with the Wait function with Ctrl-Alt-Escape
(I have tried to implement this but not succed :o(). Ok, there
is the Timeout option but ...

Note that it does not seems that there is documentation for
Ctrl-Alt-Escape in the Wait doc. For that this key sequence
works better it will be good to add to the  default key bindings: 
Key Escape A MC Nop. (I can do that ....)

Olivier
--
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: Dominik Vogt <[email-masked]>
Date: Wed, 13 Oct 1999 11:46:19 +0200

> strange (sorry if a misunderstand something).

Since there's no relevant code behind the KillModule it
doesn't really matter.  And flushing the queues if the module
is already down won't hurt either.

> Key Escape A MC Nop. (I can do that ....)

Be very careful here.  You *must not* handle X events in this
functions with fvwm's standard evevent handler (My_XNextEvent()
and DispatchEvent() functions).

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.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: Tim Phipps <[email-masked]>
Date: Wed, 13 Oct 1999 10:53:11 +0100

> and DispatchEvent() functions).

Is it possible to use XCheckMaskEvent or XCheckType Event to look for
key presses without losing other events? I suppose this might mean that
fvwm would eat all key presses when waiting for a synchronous module.

If you do implement this could the abort key be configurable (and the
one in the wait_func too). I can't use ctrl-Esc, WindowsNT grabs it and
it doesn't even get to the X server.

Cheers,
Tim.

---

From: Olivier Chapuis <[email-masked]>
Date: Wed, 13 Oct 1999 12:19:13 +0200

> > and DispatchEvent() functions).

Yes I know that and it is the problem for me, because if not I
will be able to "copy" the wait_func :o)

> fvwm would eat all key presses when waiting for a synchronous module.

Yes, I tried to use XCheckMaskEvent (with "all" the Key Mask) but I
begin
with XEvent and that did not work ... will try again. 
Note that at the present time during executeModuleSync the key presses
are catched by the window with the focus ! Maybe we have to grab
something.
However, "Mouse" events are freezed.

> it doesn't even get to the X server.

If I succeed to solve this exercise I may try to solve this one to :o),
but I am quite pessimistic with the first ...

Olivier

---

From: Olivier Chapuis <[email-masked]>
Date: Wed, 13 Oct 1999 14:12:35 +0200

> but I am quite pessimistic with the first ...

OK, I understand how executeModuleSync work now. If we want to
escape from a possible infinite block it needs to be written 
differently.
Sorry to e-mail before thinking at least 7 times (not the first
time I do that ...).

Olivier

---

From: Dominik Vogt <[email-masked]>
Date: Wed, 13 Oct 1999 14:29:49 +0200

> escape from a possible infinite block it needs to be written 

Please speak what you have in mind.  Where do you see a potentially
infinite loop?

Bye

Dominik ^_^

---

From: Olivier Chapuis <[email-masked]>
Date: Wed, 13 Oct 1999 15:09:15 +0200

> Please speak what you have in mind.  Where do you see a potentially

In the current cvs I am uneable to produce an infinite loop ;)
However, If you have an non-supported module that you start with
ModuleSync without timout and which never respond you've got
an infinite loop I presume since select is run with a NULL timeout.
So, it is probably not needed to rewrite executeModuleSync and
my first Event exercice is finish !

But it is not that that I have in mind ... I work on a general "Busy
Cursor" patch which displays a busy cursor when fvwm goes into a freeze
procedure which can take some times (as Read, PipeRead, Wait (not really
a freeze place but one may want to see that he waits something),
ModuleSync,
Recapture (allready implemented but not configurable, may cause a bad
interconnection with menu via dynamicpopuaction)). EveryThing
configurable 
with a command like: BusyCursor Option bool, ...
It allready work on my machine and it is real pretty in the case of 
a dynamicpopuaction that read long menu config (as the /dev directory 
or the gnome menu). All this leads me to try to see where there is
potential long loop.

If you think it is a bad idea say me now so I will not write the doc
(and
revert the patch on my machine).

Olivier

---

From: Dan Espen <[email-masked]>
Date: Wed, 13 Oct 1999 20:53:04 -0400

> revert the patch on my machine).

I think a patch that would show when fvwm was busy would be a good change.

--
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: Dominik Vogt <[email-masked]>
Date: Thu, 14 Oct 1999 04:30:24 +0200

> I think a patch that would show when fvwm was busy would be a good change.

I too think it would be nice to have.  But I am a bit concerned
that this may become a rich source of bugs.  I tried to code this
busy-cursor-on-startup stuff once and failed miserably because
there are so many things to carefully consider.  Don't let this
discourage you, though.

Bye

Dominik ^_^

---

From: Olivier Chapuis <[email-masked]>
Date: Fri, 15 Oct 1999 12:25:18 +0200

> there are so many things to carefully consider.  Don't let this

Hello,
Can you or someone can explain me the reason of the following line
in the beginning of do_execute_module ( in module_interface.c)

  if(eventp->type != KeyPress)
    UngrabEm();

It has something to do with the  busy-cursor-on-startup stuff ?
Is these lines really useful when fvwm executes the InitFunction ?

Thanks, Olivier

---

From: Dominik Vogt <[email-masked]>
Date: Mon, 18 Oct 1999 12:02:59 +0200

> It has something to do with the  busy-cursor-on-startup stuff ?

No, is was present in 2.0.38 already (the oldest release I have
on my disk).

> Is these lines really useful when fvwm executes the InitFunction ?

I have not the slightest idea.

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-workers" in the
body of a message to [email-masked].
To report problems, send mail to [email-masked]