2010/4/15 Ricardo Moran <richi.moran@gmail.com>

Thanks Hilaire! It would be great if we had a teacher testing our tools with his students. Now that they're public it is posible that some teacher could find them interesting :)

I must admit I'm very embarrased of not having looked at Dr. Geo until now (even though Markus told me to do it when we started this project... I should have listened to him).

Dont' worry about that, these two projects are different enought to justify different code base. However it is true it is very possible to link plotting and interactive geometry canvas. Several interactive geometric software out there do that. In that case, the locus object of DrGeo is the used tool.
Btw, have you looked at this example for plotting and tangente http://blog.ofset.org/hilaire/index.php?post/script-drgeo (english translation link in a comment at the end of the article), it use the Smalltalk User scripting facility of DrGeo.

Anyway, what you did is amazing! Truly amazing!
The thing that most embarrases me is that every geometric object in Dr. Geo is a separate morph (vectors, points, segments, and so on). This is so obvious I feel like an idiot, but I did it the other way: I made only one morph and I change its #drawOn: method. As a result it is somewhat difficult to change the atributes of a specific vector without affecting others. I will now have to fix my implementation because I didn't look at yours before :P

Yes, implementation was carefully thought to follow accutely the object paradigm: having each geometric object to be a morph give an almost free bosus: Etoys scripting. This is what lead to this choice and not the drawOn:. In the other hand, drawnOn: should be cheaper in term of CPU consumption. (in fact, I do have an additional level of abstraction with costume because at the time of implementation I was not sure about using Morphic or Tweak based canevas, but I will refactor that and remove this level)