Good morning,
> Fvwm really needs the ability to do synchronization with modules in this
> fashion. I had similar problems with FvwmIconMan when the user would use fvwm
> to move my icon manager window.
And how did you deal with it? (Or /where/ did you deal with it? I couldn't
find it in IconMan sources.)
> If so, then it shouldn't be too hard to add a new message type to handle
> this. When a module sends a command to fvwm to execute, fvwm sends back a
> packet when that command is completed. It seems that we would just have to
> send that message back after the call to ExecuteFunction() in
> HandleModuleInput() in module.c. Wouldn't be hard at all. And since your
> module would be the only one using it for now, it shouldn't be a risky thing
> to add.
Apparantly, someone already did it. At least in my fvwm2-95 v2.0.42a,
HandleModuleInput() ends like that:
ExecuteFunction(text,tmp_win,&Event,Context ,channel);
SendPacket(channel,M_FUNCTION_END,1,0,0,0,0,0,0,0);
and module.h states:
#define M_FUNCTION_END (1<<22)
And it even works (providing you take into accout the M_FUNCTION_END
following the M_CONFIG_END. So much for today's hard work). Thanks.
> Now if you are worried about fvwm doing things that your module has no way of
> knowing about, the only way to cleanly handle that is to add semaphores to
> fvwm. The odds of that happening are probably fairly slim, and easily
> controlled by the user (I quit netscape, which takes 20 seconds to actually
> quit, and in the meantime start resizing windows. I should just knowbetter).
Absolutely. That's why there's a "refresh screen" a mousedrag away. :-)
_
(_ / _ / ( E-mail pigeons nest in binary trees )
(__/__(/\_(/
--
Visit the official FVWM web page at <URL:http://www.hpc.uh.edu/fvwm/>.
To unsubscribe from the list, send "unsubscribe fvwm" in the body of a
message to majordomo_at_hpc.uh.edu.
To report problems, send mail to fvwm-owner_at_hpc.uh.edu.
Received on Wed Aug 20 1997 - 08:40:01 BST