[etoys-dev] GSoC - Progress on the graphing tools

[Ricardo Moran]

Yes, they are different and also the scope of these tools is much more
limited than Dr. Geo.
Dr. Geo is a big project and I would like to take it's implementation as an
example to develop my stuff, if that's okay with you. I also like the way
Dr. Geo uses the WheelMorph, I may borrow it :)

Richo.

PD: The example you have there it's very cool! It's not easy to reproduce
though.


On Thu, Apr 15, 2010 at 2:30 AM, Hilaire Fernandes <
hilaire.fernandes at edu.ge.ch> wrote:

>
>
> 2010/4/15 Ricardo Moran <richi.moran at 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)
>
> Hilaire
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakland.org/pipermail/etoys-dev/attachments/20100416/59ae4208/attachment.html