🚀 go-pugleaf

[Me: Scheme for exit: XtAddCleanUpProc, XtExit, etc.]

>I think these are good ideas, but there is a problem: this scheme
>would not be backward-compatible. New applications that use XtExit()
>would break existing widgets that expect their destroy procedures to
>get called in order to remove temporary files, etc.

It is backward compatible in this sense: if the application and the 
widget set go on doing the same things they were always doing, the 
same thing that happened before will continue to happen.  I agree
that if you only change 1/2 of the system, the other half will not
change automatically, and that could present problems in a few cases.

The problem that got the whole thing started was that the destroy
procedure isn't always called, unless the application programmer
is careful about it.  If both the widget and the application are
changed to clean-up procs, they won't have to be so careful in 
the future.


>I think that the application programmer should explicitly call
>XtDestroyWidget() for widgets whose documentation clearly states that
>destruction is necessary. 

Hopefully clean up procs would reduce the number of widgets for which
this is necessary.  It's too much of a hassle for the programmer, and
it limits the widget writer:  I can't change my widget to create a temp 
file because all of the existing applications would have to go back 
and change their code to make sure it was destroyed explicitly.

What I envisioned was that a widget which created a temp file would
call XtAddCleanUpProc from it's Initialize routine, and 
XtRemoveCleanUpProc from it's Destroy routine, passing the widget pointer 
as the client_data.  This creates an "ensured destroy" without changing 
the core widget structure, or bothering the 99% of widgets that don't
absolutely need their destroy procedure called.


>Another issue is the distinction between a normal exit and a crash.

How about if the callback has the following arguments:

CleanUpProc(client_data, exit_value)

Where exit_value is the value passed to XtExit().  If this is non-zero,
the clean-up proc. knows that the application is not exiting normally.


>As far as XtDestroyApplicationContext() is concerned, I think that it
>should destroy all widgets associated with the app context. Otherwise,
>XtWidgetToApplicationContext() would not be meaningful. Similarly,
>XtCloseDisplay() should destroy all associated widgets.

Whether or not all these widgets want or need their destroy procedure
called?  Wouldn't this be a waste of time?  The widget destroy proc was 
envisioned to free up Pixmaps, GCs and things from X which would not 
have to be freed explicitly if the connection to the X server were 
closing.  (Otherwise, wouldn't they have called all of the destroy procs 
in the current Intrinsics implementation?)



>Erik M. van der Poel                  erik@sra.co.jp             (Japan)
>Software Research Associates, Inc.    erik%sra.co.jp@uunet.uu.net  (USA)
>Tokyo, Japan    TEL +81-3-234-2692    erik%sra.co.jp@mcsun.uucp (Europe)

--Janet

Janet L. Carson                               internet: jcarson@bcm.tmc.edu 
Baylor College of Medicine              uucp: {rutgers,mailrus}!bcm!jcarson