Squeak on Jornada 720!

reic0024 at d.umn.edu reic0024 at d.umn.edu
Thu Jul 25 18:03:43 UTC 2002


"Andreas Raab" <Andreas.Raab at gmx.de> wrote:
> Russel,
> 
> > I think that the problems are not so much with morphic as 
> > such, but with the way the we are programming it - in particular
> > treating morphs as things to be built and rebuilt constantly rather
> > then live objects to be used and resused.
> 
> Can you say a little more about what you mean by this?!

I cannot speak definately for Russel, but this is what I took it to
mean.  If it's not what he meant, I think it still may be relevant.

For instance, if you have a group of PIM apps that all happen to use a
MonthMorph, cache that, in some class var or something.  Keep track of
it somehow.  You could use it across apps, but that may cause problems
when more than one is open.  

Another idea is to keep a default instance of the morph, and perhaps
even the model (why not?) accessible from the class side.  Let's say we
have a ContactsApp.  "ContactsApp open" opens this default instance
being held onto by some class var.  The entire morph.  It would take up
more space, but it would sure be faster to start up than having to build
the morph from scratch again, and possible read in datafiles, &c.

A real world example from my work is the visualizer (employing the
ever-so-rad PlotMorph) I wrote to look at ecology data.  Each plugin
makes it's own plotmorphs, so when you switch plugins, it makes another
8 plotmorphs.  When you switch modes within the plugin, it creates
another 8 plotmorphs.  each of those plotmorphs hold on to plenty of
other objects and morphs.  Why not just have those 8 plotmorphs set
aside always, and simple clear and add data?

In this case, it's being run on fast desktops, so speed hasn't been much
of an issue.  But it is ugly, and I plan on re-writing it with a much
more elegant way of doing plugins.

My example may suck, and I'm rambling as usual, but hopefully you get
the picture...

Regards,
Aaron



More information about the Squeak-dev mailing list