On 01.07.2009, at 19:33, Ramon Leon wrote:

>>> Mind you, I never implied that work should stop to improve Squeak  
>>> in the
>>> here-and-now (go back and read what I wrote). But for me every  
>>> improvement
>>> fits into a larger context.
>>>
>> I never implied that we should drop supporting an educational  
>> software
>> for squeak (eToys & friends).
>> Just tell me: who is currently maintains eToys in Squeak 3.10.2?

Whoever cares about Morphic.

As I explained before, Etoys development happened outside of  
squeak.org since 3.9. And even if we start fixing it now it will take  
quite some time before it is fully usable again.

Besides, it's not like all other subsystems have active maintainers,  
so there's no point in singling out Etoys.

>> If there's no-one, then wouldn't it be better to cut it out and
>> integrate later as a separate module/package (whatever you think is
>> fits for it) by people who cares?
>> When i come to shop to buy a bread & taking it to the cash desk, is
>> there anyone yelling at me, that i'm also need to pay for a bicycle,
>> because bread is not selling as a separate product?

That's a silly analogy. If I could buy a Squeak version which had  
Etoys as an optional add-on that still works, I would take that. Alas  
the way Etoys was written goes against what you would call modular  
design and hence it is not a simple add-on. It's interwoven with  
Morphic to a degree the two are hard to separate.

>> Please understand me, i have nothing against eToys. But i treat eToys
>> as an application on Squeak platform, not as a core part of it. And i
>> thinking that it should play under a common rules as any other
>> applications do: keep it as separate package.
>
> Ditto, why is so hard for some to see that eToys isn't Squeak, it's  
> an app build on Squeak?

Because it's not. Wish it was, but it isn't. I guess you never  
actually understood the code. Nobody can even draw a clear line  
between what is Etoys and what is not. And no, the system categories  
mentioning "Etoys" are not it by far.

>  If eToys was a loadable/unloadable application, no one would have  
> any problem with it whatsoever.

>>> For example, the Etoys team started 2 years ago to develop a product
>>> that got shipped to 500 thousand users by now, soon it will be a  
>>> million.
>>> They did that with only a handful of developers working part-time.  
>>> Sticking
>>> to the base system version they started out with was the only  
>>> option (as
>>> everybody who ever did serious product development can relate to).  
>>> Now that
>>> the hot development phase is over, the changes can be folded back  
>>> into
>>> Squeak proper.
>
> It doesn't need to be in Squeak at all, any version.  What it needs  
> is to be able to be loaded into Squeak like any other application.   
> There's just no justification for it being in the core image; none.

You're welcome to help make it so. It's just not as easy as ripping it  
out.

I think the discussion so far showed once more that there is wide  
agreement for Etoys having a major place in the squeak.org community.  
But the details of how it should be maintained are not well understood.

Unlike more recent Squeak additions that are nicely modular, Etoys was  
not developed as an "application" running "on top of" Squeak. It  
rather evolved in close symbiosis with the rest of the system, in  
particular the Morphic UI framework. I don't think we have enough  
resources to separate the two while keeping them alive. Maybe the best  
use of development resources would be to consider the current Morphic 
+Etoys a unit and work on an alternative, leaner UI framework? So the  
two would not step on each other's feet?

Ideas (and even more actual help) welcome.

- Bert -