Having delved much more deeply into the modules code, it seems that the modules
all use a processing loop derived from the same base, and that said loop does
poll (using select()) the output fd, to see that it is still writable, exiting
when it isn't.
Well, this probably won't work for a lot of other event-driven applications
besides my own exploration with Perl and Tk. A C application using the Xt or
Xm toolkits is likely to pass it's control to an event loop, and rely on
bound callbacks for handling all eventualities.
So perhaps a good idea would be a packet type of M_FVWM_EXIT (or just M_EXIT,
or similar) that is sent to all modules (regardless of mask, since this is a
fairly noteworthy event) by the Done() routine, before it closes the pipes.
This way, modules that care about exit events can respond to them-- a module
that is keeping some sort of running data can save it's data before exiting,
or a run-time configurable module could save it's current state. Most
importantly, modules using a higher-level event loop, such as Tk-driven or
X Toolkit-driven, can opt to route a handler for this packet.
Just a thought.
Randy
--
===============================================================================
Randy J. Ray -- U S WEST Technologies IAD/CSS/DPDS Phone: (303)595-2869
Denver, CO rjray_at_uswest.com
"It's not denial. I'm just very selective about the reality I accept." --Calvin
===============================================================================
--
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 Fri Mar 14 1997 - 16:31:05 GMT