Hi folks!
Regarding a remerge of Squeak and Etoys:
1. I do note that this thread is only posted to etoys-dev and not cross-posted to squeak-dev. Of course, checking first with the eToys developers might be a smart move, but I can't help noting it.
2. Calling some Squeak developers "eToys haters" is not an inclusive approach. I don't think there are any real "haters", but I *do* think a large number of Squeakers want the "base platform" to not be "polluted" by eToys specific stuff.
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.
regards, Göran
Göran,
Regarding a remerge of Squeak and Etoys:
- I do note that this thread is only posted to etoys-dev and not
cross-posted to squeak-dev. Of course, checking first with the eToys developers might be a smart move, but I can't help noting it.
As I mentioned in my previous email, I had tried to get this discussion going on squeak-dev in the begining of this year and would be happy to move it there. Andreas asked his question in response to another thread (getting better development tools into the Etoys image) which was just in this list. And I agree with you that it would be pointless to bring it up on squeak-dev if the Etoys developers had instead said that they would prefer to fork, but now we know they like the idea of a merge.
- Calling some Squeak developers "eToys haters" is not an inclusive
approach. I don't think there are any real "haters", but I *do* think a large number of Squeakers want the "base platform" to not be "polluted" by eToys specific stuff.
People's reactions to different features varies a lot. Take commit messages, for example: some people love them, I am slightly annoyed by them but think they are worth having, others really, really hate them. Same thing for Traits, Etoys, namespaces and so on. So I agree that calling someone is an "Etoys hater" is not a good way to start a rational discussion, but that doesn't mean it isn't true in a very few cases. I was just pointing out to Andreas that if he expected full acceptance of this idea on squeak-dev because some people who complained in the past have moved from Squeak to Pharo, he would find out otherwise.
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.
-- Jecel
etoys-dev@lists.squeakfoundation.org