The future of Morphic (Was Re: Shrinking sucks!)

goran.krampe at bluefish.se goran.krampe at bluefish.se
Tue Feb 8 06:46:37 UTC 2005


Hi Juan!

"Juan Vuletich" <jmvsqueak at uolsinectis.com.ar> wrote:
> Lex said...
> 
> > Keep in mind that we have multiple projects using Squeak.  For some, MVC
> > is fine.  For myself, MVC is attrocious and Morphic is a massive
> > improvement.  (regarding speed, load a 3.0 image sometime and see how
> > fast morphic *can* go....)  And for others--perhaps the *majority* of
> > Squeak users -- EToys is where it is at.  A Squeak without EToys is a no
> > go for the general population.  At best, such a Squeak is a fork.
> 
> I perfectly understand this. I just believe "standard", "basic", "minimal"
> or whatever should not include eToys. And probably not even Morphic.
> All these should be loadable packages. Of course, pre-made distros with
> eToys or whatever a set of users want would be good. But made by loading
> optional packages form a suitable Universe to the small main standard image.

Yes, this is of course a very good end goal. Just don't get upset if it
turns out to be too much work. I can settle for a Morphic cleaned up a
bit. :)



[SNIP]
> I am volunteering for developing and maintainig the Morphic package.
> I'm sure someone will volunteer for developing and maintaining the eToys
> package. (Or maybe they all decide to move move to Tweak).


Great! It has been noted. We (Doug and I) will be putting PackageInfos
into the stream pretty soon and then we can register corresponding SM
entries. But we will take care of that.

And Juan - you need to contact Ned Konz. Or let me rephrase that - you
*must* contact him. :)
Ned is our eToys/Morphic guru, and he has also volunteered to Steward
those parts.

So please, pretty please with sugar on top - make a team with Ned. Ok?

> There is no need to fork. In fact, this is not just to have small images.
> It actually is to avoid forks!

Yes.

> I really can't work with eToys in. If the community chooses to keep
> the big base image, at least I will need to fork, and just keep using
> my 3.7 eToys freee image.
> 
> > Juan, your work on extracting Etoys is excellent, even if it did take
> > out a few extra pieces along with it.  I hope that it gets turned into a
> > loadable and unloadable package; it shouldn't be so hard, now that
> > you've identified the list of stuff!
> 
> I have no problem with refining it so it's just the removal of eToys and
> nothing else. But I don't think making it a loadable module is a great
> idea. It would have the same problems that the shrinking methods have.
> I prefer growing a small image than shrinking a big one.
> And making it unloadable again (to load back eToys!) seems rather
> strange to me.

I got lost in what you are saying - but talk with Ned. :)

> > One last thing to keep in mind.  Things that are used a lot, become easy
> > in Squeak.  Shrinking sucks right now because hardly anyone is
> > interested enough to really work on it.  People are voting in a very
> > honest way: how they spend their time.
> 
> I believe the big decision  to make is: Do we prefer shrinking a big image
> or adding packages to a small one? I vote for the second.

Yes, I agree. But I also first just want people Stewarding parts of the
image - that means taking care of it. I really don't care at this point
if that part is actually broken out and made loadable - or if it is
being maintained "as is". Humble goal to begin with.

> > -Lex
> >
> 
> Juan

regards, Göran



More information about the Squeak-dev mailing list