Re-doing Morphic ( Was: Re: Traits prototype image )
hannes.hirzel.squeaklist at bluewin.ch
Tue Feb 11 11:50:17 UTC 2003
tblanchard at mac.com wrote:
> On Tuesday, February 11, 2003, at 04:32 AM, Ned Konz wrote:
> > We should be able to take all these things and make them separately
> > loadable packages. EToys, Piano Rolls, Stack Morph, Flaps, and the
> > One direction I was recently thinking about is this: it wouldn't take
> > too much to make a "separate but equal" Morphic hierarchy, with some
> > minimal behavior to make it play with the existing Morphic API. Start
> > at NewMorph or something, and build the widgets you really want. Then
> > move, copy, or port over the bits of the existing Morphic that you
> > want to keep.
> This sounds hard.
Look at Bob Arning's idea (sent in a few hours ago)
<BobArning>You don't even need the "equal" part of "separate but equal".
Imagine a NewMorph as different as you like. Install trial versions of
the NewMorphs in a NewWorldMorph. NewWorldMorph would be a bit special,
appearing to its owner as a simple childless morph, but to its
newSubmorphs it's a whole new world. NewWorldMorph>>drawOn: could
dispatch whatever drawing messages NewMorphs supported and these
NewMorphs could interact with their siblings, blissfully unaware of the
old morphic world where your browsers and debuggers still
First question: NewMorph would just be a subclass of Object wouldn't it?
And NewWorldMorph a suclass of NewMorph? And it needs at least a method
#drawOn: and composition logic. This would already be the nucleus of
I would like if we could persue this a bit further. Even if it doesn't
lead to THE NewMorphic it will be a good learning experience for many
here on the list and help to understand OldMorphic.
Having variants of Morphic with increasing complexity are good teaching
More information about the Squeak-dev