🚀 go-pugleaf

In article <9003052005.AA24152@expo.lcs.mit.edu> kit@EXPO.LCS.MIT.EDU (Chris D. Peterson) writes:
>
>> With regards to the the "cleaning up before exit" problem
>> recently discussed on xpert, I would like to propose the
>> following addition to the Xt Intrinsics:
>
>> XtAddCleanUpProc(routine, client_data)
>> XtRemoveCleanUpProc(routine, client_data)
>
>> These would add or remove a routine from a list of routines
>> to be called when the application exits.
>
>> To exit an application, the programmer would call:
>
>> XtExit(value)
>
>> which would call all of the clean up procedures and then
>> call exit(value).
>
>This is a good idea.  I will bring this before the internal Xt Consortium
>working group for discussion.  

You might want to make this a more general solution.  Add the notion of
interposition to the Xt intrinsics as XView does.  Then you just interpose
on the default clean up procedure to do application specific things.

The concept of "putting this callback before this other one" in the event
stream is a very powerful tool.  It makes a slight change of behavior very
easy to accomplish.

For example, in XView if I want to add to the behavior of the default
exiting procedure, I do this:
	...
	frame = (Frame)xv_create(NULL, FRAME, NULL);
	notify_interpose_destroy_func(frame, my_destroy_func);
	...

	/* This is called before the frame's destroy func (ie. I've interposed in
	 * front of it.
	 */
	Notify_func
	my_destroy_func(frame, status)
	Frame           frame;
	Destroy_status  status;
	{
	    if (status == DESTROY_PROCESS_DEATH || status == DESTROY_CLEANUP) {
		/* 
		 * do something for the application like save a file 
		 */
	    }
	    /* Now call the frame's default destroy func. */
	    notify_next_destroy_func(frame, status);
	}

If I want to change the behavior, I omit the last line:

	"notify_next_destroy_func(frame, status);"

which passes on the destroy event to the next callback.  

The concept of interposition applies to any callback in the XView toolkit.
It's a very clean solution...and would not break backwards compatibility
since it would be additional functionality.

Regards,

Heather