🚀 go-pugleaf

In article <9003022256.AA07109@moniz.bcm.tmc.edu> Janet L. Carson 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).


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.


However, I *do* think that registering clean-up procs is a good idea,
and should probably be possible for general purposes, but not for
those things that widget destroy procs are used for.


I think that the application programmer should explicitly call
XtDestroyWidget() for widgets whose documentation clearly states that
destruction is necessary. Then the application should call XtExit(),
which tells Xt to exit when it is safe to do so, that is, after
destroy phase 2. This way the app programmer does not have to set a
global flag to break out of the main loop.


There should probably also be an XtAppExit(), which would terminate
only the given application. This would only be implemented in systems
where it is possible to have multiple applications in one address
space. Similarly, we need XtAppAddCleanUpProc() and
XtAppRemoveCleanUpProc().


The default error handler should not call exit() directly. It should
call XtExit().


Also, it would be nice if widgets would be able to express an interest
in having themselves destroyed before exiting, just in case the app
programmer does call XtExit() but forgets to call XtDestroyWidget().
Of course, if the app programmer calls exit() you're hosed, but the
current situation is already like that anyway.


Another issue is the distinction between a normal exit and a crash. A
widget may want to know whether its destroy proc is being called by Xt
or by the app programmer. If it is being called by Xt, it might assume
that there was an error, and therefore refrain from unlinking its
temporary file. The widget might also like to give the app some
control over this, by having a resource like XtNremoveTempFile.


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.
-
-- 
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)