Path: utzoo!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!tut.cis.ohio-state.edu!ucbvax!agate!color.ced.berkeley.edu!spanki
From: spanki@color.ced.berkeley.edu (Frank Goodman)
Newsgroups: comp.windows.x
Subject: Re: R4 Athena Widget question.
Message-ID: <1990Feb26.192750.15430@agate.berkeley.edu>
Date: 26 Feb 90 19:27:50 GMT
References: <9002261658.AA28416@expo.lcs.mit.edu> <1990Feb24.002324.14813@agate.berkeley.edu>
Sender: usenet@agate.berkeley.edu (USENET Administrator;;;;ZU44)
Reply-To: spanki@color.ced.berkeley.edu (Frank Goodman)
Organization: UC Berkeley Center of Environmental Design Research
Lines: 49

In article <9002261658.AA28416@expo.lcs.mit.edu>, kit@EXPO.LCS.MIT.EDU
(Chris D. Peterson) writes:
> 
> Since both the operating system and the X server are clever enough to free
> up all resources associated with the client, it should be enough to just call
> exit().  You can certainly be more clever, but it didn't seem worth putting a
> bunch of code that doesn't accomplish anything into all the example programs.
> 
> 
> 						Chris D. Peterson     
> 						MIT X Consortium 
I think the important issue here is that application programmers don't know the
contents or mechanisms of a widget. A widget writer is supossed to destroy
everything that needs to be destroyed in the destroy callback. An
application writer doesn't know what gets destroyed there, and shouldn't
have to go look. He should ALWAYS allow the widgets to exit properly.
Wether or not the OS or Server free the X resources, neither one are going
to remove my widget's 36 meg temp file. Something an application writer 
shouldn't have to worry about when he uses my widget. However, if he follows 
the core examples he will fill his filesystem pretty darn fast and accuse me 
of writing a bad widget.

I look to the core programs as examples, and I'm sure others do too. It
seems to me that they should either "do the right thing" or explain why they
don't. Just because you all know that none of the Athena widgets really need
a destroy callback (given the server and OS), doesn't mean that it is safe
to assume this for all widgets. Why did your widget writers even bother
putting in these callbacks, if you summarily ignore them? If they are truely 
meant as "examples", than I will argue that it was worth the extra code to 
exit correctly. Your examples make it harder for those of us out here writing 
more sophisticated/powerful widgets because applications writers who follow 
those examples will undoubtedly have as much trouble as I did figuring out 
the cause of their problem. If widget abstractions are supposed to be 
"private" from the application, then widget writers should be able to work 
under the assumption that application writers will "know how" to use the 
widgets. However, neither the examples, nor the documentation really address 
this phenomenon and my feelings are that maybe they should.

-Frank.

P.S. I don't mean to belabor the point, but I feel this is an important
issue. By exiting the way you suggest, you are implying that application
writers should also do this. I disagree.
---------------------------------------------------------------------------
Frank  Goodman				arpa:  spanki@CED.Berkeley.EDU
University of California, Berkeley	  or:  spanki%CED@jade.Berkeley.EDU
College of Environmental Design		uucp:  ...hplabs!ucbvax!ced!spanki 
S.I.S Research Laboratory	 	phone: Novelty item, not necessary
---------------------------------------------------------------------------