Hi Subbu.

> But that was then and this is now. Instead of shooting for a reloadable
> Etoys, what if the next Squeak release makes a clean break from Etoys?

That's not what I was going for. Etoys includes hints for userful extension points in the base system. Instead of just deleting code, one could take a look at it and rewrite it to present a less invasive extension. ;-) This takes some effort, of course.

Best,
Marcel
Am 29.01.2021 13:22:54 schrieb K K Subbu <kksubbu.ml at gmail.com>:
On 29/01/21 2:54 pm, Marcel Taeumel wrote:
>
> Morph >> #player in "Morphic-Kernel" / "accessing"
> BookMorph >> #goto: in "MorphicExtras-Books" / "navigation"
> HandMorph >> #pasteMorph in "Morphic-Kernel" / "paste buffer"
> Morph >> #isTileMorph in "Morphic-Kernel" / "classification"
> HaloMorph >> #addTileHandle: in "Morphic-Widgets" / "handles"

IIRC, Etoys was an experiment in visual programming for children too
young to program via text but made fairly (hindsight!) intrusive changes
to Morphic. Etoys was organically bound into Squeak; like conjoint twins.

But that was then and this is now. Instead of shooting for a reloadable
Etoys, what if the next Squeak release makes a clean break from Etoys?

I propose that we slim down Squeak by removing all Etoys-related code by
without trying to ensure that existing Etoys package successfully loads
back into the image. This will slim down Squeak significantly and ease
its maintenance.

The largest user base for Etoys was on XO laptop. Those users are
unlikely to upgrade to new Squeak. Also, porting Etoys package to load
into slimmer Squeak may be an easier and better way to continue research
than striving to maintain both in the released image.

Regards .. Subbu

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20210129/327c797b/attachment.html>