On 22.05.2011, at 21:49, Ricardo Moran wrote:
Hi guys, following Bert's request I've resumed some of my work for GSoC hoping that it could be included in the next Etoys release :)
Great! :)
This is a new version (a complete rewrite, actually) of the graphing tools. This time I've followed Steve's idea of a simple number line object and the ability to change the scale of the playfield so that kids could make their own graphs (you can find the original conversation in this old thread).
You can see in the attached project that the playfield includes two new objects (horizontal number line and vertical number line). This objects have an extra category called "number line" with a few properties such as:
- increment
- min/max value
- scale
You can change the scale to define how much pixels will mean a unit of the number line. The increment will define the distance between labels.
You will also find a new category on Playfield named "coordinate system". This category has:
- origin at center?
- origin
- scale x
- scale y
Using this properties you can define a different coordinate system for the objects you throw inside the playfield.
In the attached example I defined a playfield with the origin at 50@50 (this means 50 pixels from the bottom and left sides), an x scale of 1, and an y scale of 30. You can see how the position of the star changes acording to this scale while you move it inside the playfield and how it returns to its original scale when you pick it up and drop it outside the playfield.
For now it's just a proof of concept. A lot of things still don't use this new scaling (i.e. #forward:). But I want to know what you think about this direction.
I'm hesitant to follow this particular direction. Implementing another scale on top of the existing scaling seems like it may lead to lots of problems. There already is a scaleFactor. Your approach from last year was too "specific", this now I find too general ;)
Possibly you could make it work by using the scaleFactor we already have. This would automatically work for the size of objects, forward-by etc. But we have not really used scaling in Etoys because it really is bitmap-based, the rendering of scaled objects is not nice. So for practical reasons we don't really use scaling.
However, for your charts I'd think we should leave the graphical scaling alone. Rather, the number lines would be a gauge that measures the values represented by the object's position or size. So e.g. the axes in your example might show a 30:1 scale. When asking the axis for the value of the star, it would calculate the distance from its origin and divide by 30. But that value would always be relative to the axis, not an intrinsic property of the object.
To actually access that object's value there should be a "current" object. This could be done by using the playfield's cursor. You would select the object as the current one, and then e.g. access "current object's position in chart" or "current object's size in chart". The former would be for point charts, the latter for bar charts.
If we go that route we could even have multiple horizontal scales for the same data ... hmm, maybe that would be too confusing. But am I making my thinking clear?
As an aside on code style, please avoid too generic names for special concepts. E.g. methods named "x", "y", "origin" that have a specific meaning in context but are way too general as a method name for every Morph.
Btw, how about naming your package "Charts"? It's better than "GSOC" for sure ;) You also used "Graphing" but I'd let a native speaker / teacher comment on what would be most appropriate.
Also, how much time do we have until the deadline? I have two exams tomorrow so I'm probably off for today.
Well, I'd say it's ready when it's done. I would like to do a 4.1.2 bug-fix-only release soonish, and the actual 2011 Etoys release with new features like this some time later this year.
We can discuss this stuff at SqueakFest :)
Yes, please discuss. Would be awesome if I could be there too, but alas, not this time.
- Bert -