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

[karl ramberg]

On Fri, Apr 16, 2010 at 10:24 PM, Ricardo Moran <richi.moran at gmail.com> wrote:
> 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.

I wonder why you don't use PolygonMorph for vectors ?

Karl

>
> 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
>
>
> _______________________________________________
> etoys-dev mailing list
> etoys-dev at squeakland.org
> http://lists.squeakland.org/mailman/listinfo/etoys-dev
>
>