[etoys-dev] together again

[Bert Freudenberg]

On 05.10.2009, at 10:46, Serge Stinckwich wrote:

> 2009/10/5 Göran Krampe <goran at krampe.se>:
>> Hi!
>>
>> Jecel Assumpcao Jr wrote:
>> [SNIP of stuff we agree on]
>>>>
>>>> I really like eToys but I have not looked deeply at its  
>>>> implementation
>>>> and what a "merge" entails. I think a majority of Squeak-dev  
>>>> would like a
>>>> merge... *IF* it means keeping eToys a separate layer/entity that  
>>>> can load
>>>> on top of the base.
>>>
>>> Note that the official Squeak images already include Etoys. so a  
>>> merge
>>> would not imply adding that. It would, instead, mean adding lots of
>>> little fixes and some new functionallity (like scaling the screen  
>>> or the
>>> new navigation bar).
>>>
>>> We all agree about how great it would be to have a tiny kernel image
>>> that could load an Etoys layer, but that is not going to happen  
>>> soon.
>>> People have created scripts in the past that can rip out all the  
>>> Etoys
>>> stuff but always in such a way that it is a one way street: the  
>>> result
>>> can't be loaded back in. We know what needs to be done to go  
>>> beyond that
>>> and have a reloadable layer, but none of us has the time to do it.  
>>> So
>>> putting this on a roadmap for the near future is sure to lead to
>>> disappointment.
>>
>> Well, still, it is a crucial point. Let me outline two different  
>> scenarios
>> of which I would only support one:
>>
>> Scenario 1:
>>
>> - eToys and Squeak-dev merge by simply moving all changes made in the
>> eToys-fork to the eToys code inside Squeak.
>>
>> - Work continues on improving eToys inside Squeak based on the  
>> needs of the
>> eToys project. The code is still intertangled with the rest of  
>> Squeak. There
>> is no clear boundary and we will see eToys specific code in the "core
>> classes" (especially Morphic I presume).
>>
>> Scenario 2:
>>
>> - eToys and Squeak-dev merge by moving all changes made in the  
>> eToys-fork to
>> the eToys code inside Squeak BUT also clearly marks a boundary  
>> between eToys
>> and Squeak. This can be done using method categories and whatever  
>> means
>> necessary. While it can not easily be snapshotted separately we at  
>> least
>> KNOW what it consists of.
>
> IHMO this is a bad idea to continue to mix Squeak and eToys code. As
> you say, EToys should be a separate entity from Squeak or Pharo.
> For example, Seaside is not embedded in Squeak, this is a completely
> separate product.
>
> This could be a win-win situation for both communities : Squeakers or
> Pharoers will be happy to move and clean their platform without the
> fear to break the entire Etoys stuff, EToyers will have access to a
> more secure and well-maintained core base. As the EToys removal
> experience of Pharo has shown, EToys code encrust every aspect of the
> Squeak platform and is not really good from of point of maintenance of
> the system in the long run.

IMHO the only viable way to do this is to declare Morphic as part of  
Etoys, and maintain the two together. There can be alternate UI  
frameworks - we still have MVC, and there are a couple of other  
contenders (and using ToolBuilder it is possible to have tools working  
under any of them). Etoys code does not stretch too far into the rest  
of the system I think, but is very closely related to Morphic.

- Bert -