[Re: Morphic] Some feedback about the package organization

Hi Stef and Juan (and Edgar),

I looked at this proposal. And thoght about it for a
day. And realized I had some partial feedback.

Stef, what is your idea of Morphic-core? And what
would be widgets and what would be extraWidgets? And
what, if anything,would be left out entirely?

The catagories being proposed seem to divide morphic
horizontally. What about the vertical divisions? For
example. I’m aware of several parallel ways of
thinking about things.
Rectangle/Ellipse morph i.e. everything that relies on
TransphormationMorph. Andreas’s stuff that relies on
MatrixTransformations. This includes the truetype
stuff. And Polygons which handle Transforms on their
own w/o relying on Tform stuff.

As descriptors Core,Widgets and ExtraWidgets, and
Oldies do not suggest much difference to the
imagination.  A separtion by function would help by
being more descriptive

I don’t have a good idea of at this point for a good
set of functions.  Organizing, Choosing/Picking,
Handles. Menus something along those lines. Without
looking at the totality of things, its hard to guess
what good catagories would be.

I don’t have a big stake in what choices get made
here, unless they effect the ability to create and
publish new stuff.

"Good results come from making Good choices. Good
choices come from experience. Expericence come from
making poor choices."  -Source unknown.  

Might’s well let the fun begin.

Yours in service, --Jerome Peace




>[Morphic] Some feedback about the package
organization do you mean by "a  
>> layered architecture"?
>
>instead of two big packages Morphic and Morphic
Extras Morphic that only  
>contains (no code)
>but just the other packages as required packages. I
think that this  
>is the best way to manage configLine of entities
>changing together. This way refactoring or cleaning
Morphic would imply:
> loading the map and saving it and its package at
once but still make  
>sure that we can remove part. but for now we do not
>really need to worry about that.)
>
>As an example...
>The idea would be that we can remove as much as
possible
>and only load what we want:
> for example some packages such as LedMorph are
excellent and well-
>self contained and coherent
> while other are just a bag of stuff and other have
lot of reference  
>to other packages
>
>> BTW, if I remember well, CDScreenShotMorph was
touched about a  
>> month ago, and I tested it as the contributor of
the code said (was  
>> it Jerome?), and everything looked fine... Let me
take a look.
>For this one, I would put it into the
> MorphicSimpleExamples
The CDScreenShotMorph is a nifty presentation tool. It
was not actual meant to be a code contribution only a
testing support for the Fix that was proposed.  I have
cooked the essence of it into a subclass of ImageMorph
called PopupThumbnailMorph which uses the target
sighter rather than drag and drop to choose what it
displays.  Its designed to be a presentation tool. You
illustrate what you are writing about with the
thumbnail and the reader can see greater detail by
pressing the thumbnail image.  At least that’s what
Lex Spoon its creator used it for.


>
>

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around
http://mail.yahoo.com 
_______________________________________________
Morphic mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/morphic