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

[Ricardo Moran]

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.
* 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 :)

Cheers
Richo


>
> - 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>