On 10/31/06, goran at krampe.se <goran at krampe.se> wrote:
>
> Hi!
>
> "Laurence Rozier" <laurence.rozier at gmail.com> wrote:
> > I don't support what Juan's proposal as stated. I'd like to hear why
> you,
> > Juan or anyone else don't agree with what Jecel/Guy proposed
>
> Ok, let me quote so that you don't need to skip back, Jecel wrote:
>
> > This is a plan that is practical and which I fully support: if we can
> > unload eToys but not load it back, then let's just include eToys in the
> > full image that we distribute and allow everyone the one way option of
> > removing it. I don't mind at all eliminating the Flash logo, the welcome
> > windows and other stuff every time I begin working with a newly
> > downloaded image. The fact that I can't get any of these easily back if
> > I want has never been a problem since I could just start over from a
> > clean image.
> >
> > Sure, a reloadable eToys would be even better but I doubt it will
> > happen.
>
> My problem with that proposal is that it means that Morphic is actually
> not cleaned up - it would just persist as it is today.


... I can see your point but what I had in mind was cleaning up Morphic and
being able to "revert to the old Morphic with eToys" ... this is btw also
where Spoon comes in(more below) and makes me wonder if there isn't a middle
ground that would automatically detect whether a project being loaded is
using old Morphic and then load that project as an isolated project along
with old Morphic?

It also means that any cleanup that such a removal-script would do in
> itself (and Juan has already said that such a delta script is NOT easy
> to maintain IIRC) would actually fork Morphic itself - people writing
> code on top of Morphic in the future would have to wonder if it is being
> run in the image-with-a-clean-morphic-without-etoys or in the
> image-with-etoys.

In other words, the above sounds like either "status quo" or a fork of
> Morphic.

I dislike both. :)

Note that eToys is not a clean "addon" on top of Morphic - it is in fact
> an intertwined mess with Morphic methods including lots of logic
> specifically for eToys. So if you clean out eToys you end up with a
> different Morphic.


Agreed. However, eToys was originally presented as a Morphic add-on and that
is the impression many(most?) new comers will continue to have.

I think it would be much better to lift the burden of eToys, let Juan do
> his magic and give us an improved Morphic in the baseline - let anyone
> step up and retrofit eToys on top of that as a cleaner addon, or not.


 I understand the difficulties, but since it's taking away something that
currently works, the onus is on the remover in my view.

In
> either case - Squeakland is the place to go for eToys and has always
> been.


 Oh if only it were that simple. Now if etoys had started out in a forked
image that would be simple, but from the beginning etoys was in the only
squeak image. IIRC the early browser plugin images were based on the current
Squeak image. The Squeakland website has and continues in many places to
make reference to Squeak without distinction and Google has recorded tons of
this. No amount of assertion here will change that fact. We can decide that
it doesn't matter, but it will be a long time before the close association
between squeak.org and etoys is gone. Until then people who are attracted to
Squeak because of etoys will continue to have bad impressions. This video
<http://video.google.com/videoplay?docid=2933987255545037916>makes it clear
though it is somewhat painful for Squeakers regardless of what distribution
they use to watch because it's not only about the etoy experience. Squeak
and Smalltalk have done this over and over - we can't blame

> >if we can unload eToys but not load it back, then let's just include
> eToys
> > in the
> > >full image that we distribute and allow everyone the one way option of
> > >removing it.
> >
> > which mirrors what I said in "Smalltalk Reloaded". More specifically, do
> > folks supporting Juan's proposal disagree with my statement:
> >
> > >All other considerations aside, if e-toys is unloaded from the main
> > distribution and cannot be easily reloaded by a new Squeaker,there will
> be
> > confusion and for many disappointment and/or some other non-positive
> > experience.
>
> I am not sure I agree with this.

Thing is, eToys in the "main distro"
> (squeak.org) has been relatively unmaintained for some time I think
> (others with better knowledge might disagree). I personally would not
> trust eToys in official Squeak to work as one would expect it to work
> relative to the Squeakland image.


I understand but most people coming to the Squeak site don't have your
perspective.

And this goes especially for 3.9 and beyond, since Squeakland is 3.8
> based.
>
> So to rephrase myself - if we aim to minimize the risk of a non-positive
> experience of eToys I think we should clearly and distinctly direct
> people towards the Squeakland distro directly from the main page of
> Squeak.org for those people looking specifically for eToys.


That makes it less non-positive but it's still not an improvement IMO until
the new morphic is used for something ... well new.

> For me it's not that I'm opposed to a cleaner Morphic, I just don't want
> to
> > add stumbling blocks for wider acceptance at a time when eToy images are
> > getting more and more visibility. Sure it would be nice to see the
> default
> > image with a cleaner Morphic but not at any price - especially since
> Spoon
> > is coming.
>
> Mmmm, I don't see how Spoon relates technically to a cleanup of Morphic.
> I consider those two efforts quite separate.


The etoy/morphic entanglement will eventually yield to imprinting and with a
dynamically configurable image, we'll get the best of both worlds.

> It's not clear to me whether the upside of a cleaner Morphic wil=
> > l
> > be that great or long lasting because I believe we're in the early
> stages o=
> > f
> > a big paradigm shift in which Croquet
> > UI<
> http://www.meshverse.com/2006/10/18/the-64-billion-dollar-question-reloa=
> > ded/>(oh
> > where is Wicket?) is where the action is. In this new paradigm, I don't
> kno=
> > w
> > whether a cleaner Morphic is going to have advantages over Tweak.
>
> It is not so much about which is "best". Tweak is radically different,
> and many of those ideas are great (AFAICT). I have on the other hand
> heard people moaning about it being hard to debug and as we all know -
> it is not "ready" for Squeak.org yet. Again AFAIK.
>
> I don't think we should sit around and wait for Tweak to save the day -
> we have already done so to a certain extent and I think we should stop
> doing that. Morphic is nice and it can be small and lean too. Juan
> offers to give us that and I think that is great.


It is and I wouldn't mind at all seeing it but not at the price that's
required for benefits that are not proven. If developers take the new
etoyless, improved Morphic and start doing great things with it then a
strong case can be made to break with the old. But that's not known yet, we
could end up with a core Squeak that can't use etoys AND doesn't have much
new to show because more people decide to go with Tweak or wxWidgets or ...

Also - yes, the Squeaklanders did spend time to update eToys in 3.8 with
> the changes that were done in the Squeakland image. But will they keep
> that up? I am very unsure about that, would be neat to hear more from
> Michael Rueger (or someone) on that issue.
>
> If they indeed have an intention of maintaining eToys in 3.9 and beyond
> (which I doubt) then that would indeed make the question more
> complicated.
>
> > Cheers,
> >
> > Laurence
>
> regards, Göran
>
> PS. I don't claim the almighty truth - these are just my opinions based
> on my perceptions and hunches. :)


I feel the same way. I also am looking at the history of Smalltalker's being
our own worst enemy because we didn't consider how big an impact we could
have if united in one interoperable ecosystem.

Cheers,

Laurence
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20061031/a2532d32/attachment.htm