Smalltalk › Frameworks & Tools › eToys Development

New Graphing tools

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

5 messages Options

Ricardo Moran

New Graphing tools

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 :)

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.

Also, how much time do we have until the deadline? I have two exams tomorrow so I'm probably off for today. We can discuss this stuff at SqueakFest :)

See some of you in Montevideo!

Cheers,

Richo

_______________________________________________
etoys-dev mailing list
[hidden email]
http://lists.squeakland.org/mailman/listinfo/etoys-dev

NewGraphing.004.pr (90K) Download Attachment

Steve Thomas

Re: New Graphing tools

Ricardo,

Love it! I especially like the idea of scaling (I think Karl had an idea like this a while back as well).

Interesting how setting x to 0 has 0 = 2.220446049250313e-16 (close enough +/- epsilon?)

Stephen

On Sun, May 22, 2011 at 3:49 PM, Ricardo Moran <[hidden email]> 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 :)

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.

Also, how much time do we have until the deadline? I have two exams tomorrow so I'm probably off for today. We can discuss this stuff at SqueakFest :)

See some of you in Montevideo!
Cheers,
Richo

_______________________________________________
etoys-dev mailing list
[hidden email]
http://lists.squeakland.org/mailman/listinfo/etoys-dev

Bert Freudenberg

Re: New Graphing tools

In reply to this post by Ricardo Moran

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 -

_______________________________________________
etoys-dev mailing list
[hidden email]
http://lists.squeakland.org/mailman/listinfo/etoys-dev

Karl Ramberg

Re: New Graphing tools

In reply to this post by Steve Thomas

I was thinking of using 'forward' together with griding so 'forward' would mean move one grid space, not one pixel.

I have been thinking of the unit pixel in Squeak and how it is not really explained anywhere I know of.

http://tracker.squeakland.org/browse/SQ-682

Karl

On Mon, May 23, 2011 at 5:25 AM, Steve Thomas <[hidden email]> wrote:

Ricardo,

Love it! I especially like the idea of scaling (I think Karl had an idea like this a while back as well).

Interesting how setting x to 0 has 0 = 2.220446049250313e-16 (close enough +/- epsilon?)

Stephen

On Sun, May 22, 2011 at 3:49 PM, Ricardo Moran <[hidden email]> 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 :)

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.

Also, how much time do we have until the deadline? I have two exams tomorrow so I'm probably off for today. We can discuss this stuff at SqueakFest :)

See some of you in Montevideo!
Cheers,
Richo

_______________________________________________
etoys-dev mailing list
[hidden email]
http://lists.squeakland.org/mailman/listinfo/etoys-dev

_______________________________________________
etoys-dev mailing list
[hidden email]
http://lists.squeakland.org/mailman/listinfo/etoys-dev

K K Subbu

Re: New Graphing tools

On Monday 23 May 2011 6:35:00 PM karl ramberg wrote:
> I was thinking of using 'forward' together with griding so 'forward' would
> mean move one grid space, not one pixel.
I like this idea but not its connection with "snap to grid" option (this is
related to layout not co-ords). Pixels are implicitly defined by DisplayScreen
geometry and Mouse co-ordinates both of which are related to physical
dimensions. Projects will be distorted when viewed in a web-browser on screens
with different aspect ratios.

In "Basic" category, turn-by and heading use abstract units (angles) while
forward-by uses physical units. Grid units will make all numbers absract (i.e.
pure magnitude). The default grid can be tweaked to compensate for screen
aspect ratios.

Subbu
_______________________________________________
etoys-dev mailing list
[hidden email]
http://lists.squeakland.org/mailman/listinfo/etoys-dev