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

[Ricardo Moran]

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
> >
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakland.org/pipermail/etoys-dev/attachments/20100417/9bbe7117/attachment.html