[Etoys-notify] [JIRA] Commented: (SQ-232) Simple test project demonstates problem with objects embedded into rendered morphs

jira at immuexa.com jira at immuexa.com
Tue May 12 14:17:34 EDT 2009

     [ http://tracker.immuexa.com/browse/SQ-232?page=comments#action_34622 ]
Jerome Peace commented on SQ-232:

Hi Scott,

I've downloaded the fix and will look at it.

My imaginative bug tracking assistant Puck, pleasures in finding bugs where others fear to tread. 

He is rather amazed that most developers aren't curious about the extreme cases. He always figures there is the most mischief there.

Squeak is full of limitations where things cannot be used because they behave poorly under certain circumstances. Getting away from YATMB's is what drove me to want polygon morphs to imitate ovals.

It seems to me that surely someone will want their flea morphs to move even while embedded in rotating dog morphs.

This bug is in the nature of an integration bug. Two behaviors, built for different contexts, clashing.

You can expect the user to adapt to the problem by avoiding the clash. They will do that in self defense. Then the language gets defined by its limitations. High threshold, low ceiling is exactly the opposite of Seymour Papert's motto. Is it worth the effort to remove those clashes from the child component of squeak instead? Resources being limited it's not easy to answer. Glad you took a shot at this one. 

Cheers --Jer

> Simple test project demonstates problem with objects embedded into rendered morphs
> ----------------------------------------------------------------------------------
>          Key: SQ-232
>          URL: http://tracker.immuexa.com/browse/SQ-232
>      Project: squeakland
>         Type: Bug
>   Components: etoys
>     Reporter: Jerome Peace
>      Fix For: review
>  Attachments: dizzy and confused.003.pr, dizzy.pr, forwardFix-sw.1.cs.gz
> The transformation morph used for rendering fights the basic concept of morphs being built up by agglomerating other morphs.
> In particular when you embed a morph then tilt its owner. The direction of the embedded morph gets a little confused as does its idea of where the boundaries of its owner lie.
> I don't have a good solution for this bug. A while back I did come up with a very simple illustration of it which I put in project form.
> This bug report is an excuse to upload the project.
> It helps document the current state of a rather intractable problem.
> What should happen is the moving pieces should continue their journey's w/o bouncing til at real edge of their tilted container.
> Their is no estimate of the time. Trying the test is very simple. 5m
> Fixing things so the tests work right. Is indefinite at this point.

This message is automatically generated by JIRA.
If you think it was sent incorrectly contact one of the administrators:
For more information on JIRA, see:

More information about the Etoys-notify mailing list