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

[karl ramberg]

On Sat, Apr 17, 2010 at 7:09 PM, Ricardo Moran <richi.moran at gmail.com> wrote:
> I think the projects I submited to the showcase can now be seen at:
> http://squeakland.org/showcase/project.jsp?id=9781 and
> http://squeakland.org/showcase/project.jsp?id=9782

I think id=9782 is private, I can't access it .

The first one works great. I have to play with a little more before I
can give more
feedback.

Karl

>
> On Sat, Apr 17, 2010 at 1:08 PM, Ricardo Moran <richi.moran at gmail.com>
> wrote:
>>
>> Because I'm dumb :)
>> No, actually, I started modifying the #drawOn: method to draw the grid,
>> the axis, and all the background. It seemed to me like the right way to do
>> it. Then I realized my code wasn't efficient enough so I move the drawing
>> into a separate form and I redraw it only when it was necessary. This worked
>> nice and I started to draw the data the same way. I didn't see the problem
>> until I made the vector stuff.
>> Anyway, this is fixed now. I tried uploading the project example to
>> squeakland showcase but when I tried to login from etoys it throw me an
>> error. I guess I'll try again later.
>>
>> On Fri, Apr 16, 2010 at 6:28 PM, karl ramberg <karlramberg at gmail.com>
>> wrote:
>>>
>>> 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
>>> >
>>> >
>>
>
>