[etoys-dev] Copying Graphing tools and Speech Bubbles to Inbox

Ricardo Moran richi.moran at gmail.com
Tue Aug 10 10:28:22 EDT 2010

Hi Bert, thanks for reviewing my code!

On Mon, Aug 9, 2010 at 6:20 PM, Bert Freudenberg <bert at freudenbergs.de>wrote:

> We should not add a package named "GSoC". Rather, move the
> classes/extension methods to the appropriate Etoys or Morphic package. Also,
> give them an appropriate name (the prefix "GSoC" will not make sense next
> year).

Yes, it doesn't make sense. I'll move it to the Etoys package.

> GSoCTextMorph, GSoCScrollPane: do we really need new classes for this?
> Can't the behavior incorporated in the existing classes?

I knew this classes wouldn't stay long but at the time I didn't want to
modify existing classes so I hacked my way out :)

GSoCScrollPane simply defers halo to its interior. I think this could be
added to ScrollPane without problems.

GSoCTextMorph adds the following behavior:
* It asks the compiler to execute its string in order to get its numeric
value, then it checks if the returning value is a number. I know this is
totally insecure but it's nice to be able to write "1/3" and get the correct
result :). This feature forced me to create the SyntaxErrorOmission class,
which is another hack. I could live without this if you think it's not worth
* It passes the focus to the next morph when the enter key is pressed. I
could add this to TextMorph with a boolean property to avoid imposing this
behavior to regular TextMorphs.
* It changes its border color to red when it gets the focus. I could also
add this to TextMorph with a boolean property.

> Also, all the new Player subclasses are a bit problematic. The canonical
> way is to just add the methods to Player itself (see the chat log).

I don't really like adding methods to Player, I thought it wasn't necesary
since "look like" was changed but I didn't take into account replacing
receivers. I'll remove all my Player subclasses.

> We don't want a new class Vector, nor a method to: in Point.  It does not
> really seem useful enough to occupy that name. Also, VectorMorph is just a
> PolygonMorph - why subclass that at all?

> PointMorph seems particularly hacky. Is the whole point of this class to
> have an update method? Why can't any morph be used as a point in a diagram?

The #to: method and the Vector class are not needed at all, but VectorMorph
(as well as PointMorph and BarMorph) adds a specific viewer category to
handle its properties inside a graph. I don't know how to implement this
without making specific subclasses.

> So much for now. The educators really like your additions, now we just need
> to get the code into shape for inclusion :)
> Thank you for working on this!

Thank you very much for taking the time to review my code. I'll fix the
things you mention ASAP so it could be included in the next release :)


> - Bert -
> _______________________________________________
> etoys-dev mailing list
> etoys-dev at squeakland.org
> http://lists.squeakland.org/mailman/listinfo/etoys-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakland.org/pipermail/etoys-dev/attachments/20100810/49263285/attachment.html>

More information about the etoys-dev mailing list