I was just reading through the Mac OS X documentation for OpenStep and thinking the very same thing.  If morphs knew how to write code to duplicate themselves, perhaps with some parameters (like a model), or to generate code that would openInWorld, perhaps building Support Morphs to facilitate the GUI for project building, but which are "transparent" to the codeWriters (or a repository for special purpose code that gets built into the codeWriters), that might be really neat.  

Indeed, it might also might be an order of magnitude "deeper" than a GUI projectbuilder -- you could just refactor the code and, glory be, there's your App.

> -----Original Message-----
> From: MIME :chrisn at Kronos.com > Sent: Tuesday, February 01, 2000 1:27 PM
> To: squeak at cs.uiuc.edu
> Subject: Generating source code from Morphs [was: RE: More Widgets for
> Squ eak....]
> > > Hi Lex & Company.
> > On February 01, 2000, Lex Spoon [lex at cc.gatech.edu] wrote:
> > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> "Sort of.  Morphic is nice in that you can drag things around > and embed them
> in each other.  Using this facility plus inspectors, you can create an
> arbitrary window this way.  It pretty much has the feel of a > GUI builder,
> except there is no way to generate code to recreate the thing."
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> > You know, I have often wished that this mechanism were more > robust, as it is
> much easier to drag-n-drop widgets together than it is to > wire them up the
> old fashioned way.  Perhaps the top level morph should have a standard
> selector that can generate a method definition that can later > be used to
> rebuild the whole thing programmatically.  Thus you could hook morphs
> together, embed them into a SystemWindow or playfield and then ask the
> SystemWindow to generate code that can reproduce the whole mess...  I
> suppose the first thing to do is to implement Morph>>asSourceCode. Or
> something like it.
> > Cheers!
> > ---==> Chris
> > > >