Hi all,

I was wondering if it is possible to make the main OS window border transparent whilst keeping Squeaky output.
That way one could have a purely Squeak looking application.

Thanks,

Stewart

----------
From: 	Pennell, David
Sent: 	Wednesday, April 19, 2000 8:37 AM
To: 	Squeak List (E-mail)
Cc: 	'marcel at metaobject.com'
Subject: 	RE: Old call for volunteers still up to date

<<File: ATT00001.htm>>

> > Thanks for the explanation.  Between this and your previous post
> > and a lot of ALT-M and ALT-N's, I think I finally understand.
> 
> Great!  It seems that I may have been a little less obtuse than  
> before.  What would you add/subtract/change in the explanation so I  
> can write some understandable documentation?

I'm not sure.  I looked at the encoder class hierarchy a few months
ago and came away completely befuddled.  I read your last mail several
times with intervening looks in the image and it finally "clicked".
Perhaps write-up tied to a modest example would be best.

> > My own spin:
> >
> > - Externalizing encoding is "a good thing" because you can never
> >   anticipate all of the environments that your objects will live
> >   in.  [e.g. FormCanvas/PostScriptCanvas, SQLDatabase/ObjectDB,
> >   CORBA/XMLRPRC, etc.]
> 
> Exactly my opinion.  As a matter of fact, the pipeline architecture  
> makes it possible to also separate low-level from high-level coding  
> issues.  For example, you can have a hierarchy of XML-coders that  
> deal with mapping objects to different DTDs but without generating  
> actual bytes, and then have a second layer of byte-encoders that  
> generate (a) nicely formatted XML (b) compact XML (c) binary XML  
> (WAP)  (d) ...  But this additional factoring can follow when  
> necessary, it needn't be done up-front.
> 
> > - An external encoder is a convenient place to put all the support 
> >   methods needed.  This is especially true when the client object
> >   only common ancestor is Object or another similarly broad class. 
> >   This is hard to illustrate with #printOn: because it doesn't
> >   typically need much support other than #nextPut:, 
> #nextPutAll: and 
> >   #print.  It easier to see in the Canvas examples.
> 
> While it may not be the best example, I think that #printOn: could  
> benefit from EncodingFilters.
> 
> For example, the Number -> ASCII conversion code could reside in a  
> #printOn-filter.  That would allow the conversion to be  
> parameterized, instead of those parameters being hard-coded as they  
> are now.

It might be interesting to implement something like David N. Smith's 
formatter code as alternative #printOn:'s.
 
> The collection support code can also simply be inherited from the  
> FlattenEncoder, and different versions of #printOn: for specific  
> purposes become easy to support.  I may be remembering this  
> incorrectly, but some requested #printOn: changes sounded like  
> conflicting goals.
> 
> > - Extending this framework with DecodingFilters would be 
> interesting. 
> 
> Yes, probably.  As a matter of fact, my Objective-C XML  
> scanner/parser is somewhat modelled after EncodingFilters ( 
> well, the  
> name is different there).
> 
> > - Double-dispatch and pluggable objects are certainly powerful
> >   implementation techniques, but produces code that is difficult to 
> >   read (at least to me).  Has anybody seen or thought about 
> ways to  
> >   improve this?
> 
> Yes (less readable) and not really (improvements).  Documentation  
> explaining the interfaces would probably help a lot in this case,  
> because lots of care has been taken to make the interfaces easy to  
> use and absolutely minimal.  For those goals, readability was 
> made to  
> suffer a little. :-)

Class comments would be a good start.  I think you could move a lot
of the hierarchy out of "Postscript Filters" and into something more
generic, like "Encoding Filters"...

-David

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/ms-tnef
Size: 3716 bytes
Desc: not available
Url : http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20000419/0517778d/attachment.bin