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

[Ricardo Moran]

Hi, I've just uploaded a new commit to the inbox. It contains all the
graphing tools and speech bubbles with most of Bert's suggestions fixed. I'm
sorry for the big commit but I moved my older commits to treated because
they were incomplete. Now the only commits needed to have these tools
working properly are: Morphic-Richo.33 and Etoys-Richo.32
I hope they got accepted into Etoys. I'm excited :)

Cheers
Richo


On Tue, Aug 10, 2010 at 11:28 AM, Ricardo Moran <richi.moran at gmail.com>wrote:

> 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/20100814/844a6769/attachment.html>