x-y plane questions

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|

x-y plane questions

Steve Thomas
Scott,

I started looking at the code and was able to change the tick mark width's for the number lines and playing with the marksWidth/marksHeight.
Part of the issue I was having was that the GraphPaper's line width was 1, but the mark's with was 2, so there was no way to center them.
See samples below:
Inline image 1

But I couldn't figure out how to change the pixel width of the graph paper, could you point me in the right direction, thanks.
Also any hints on how can I set the rotational center of the number line to its "0" point?  I can do it with Etoys tiles, But need hints on where would I modify the code and figure out the zero point.

Thanks,
Stephen

_______________________________________________
etoys-dev mailing list
[hidden email]
http://lists.squeakland.org/mailman/listinfo/etoys-dev
Reply | Threaded
Open this post in threaded view
|

Re: x-y plane questions

Ricardo Moran


On Sun, Mar 18, 2012 at 10:12 AM, Steve Thomas <[hidden email]> wrote:
Scott,

I started looking at the code and was able to change the tick mark width's for the number lines and playing with the marksWidth/marksHeight.
Part of the issue I was having was that the GraphPaper's line width was 1, but the mark's with was 2, so there was no way to center them.
See samples below:
Inline image 1

But I couldn't figure out how to change the pixel width of the graph paper, could you point me in the right direction, thanks.
Also any hints on how can I set the rotational center of the number line to its "0" point?  I can do it with Etoys tiles, But need hints on where would I modify the code and figure out the zero point.

Hi Steve,

I think you can change the rotation center to its 0 point by evaluating this:

For horizontal number lines:
self rotationCenter: ((self left + self offset + (0 - minValue * pixelsPerUnit)) @ (self top + self marksHeight)) - self topLeft / self extent * 1.0
 
For vertical number lines:
self rotationCenter: (self left + self legendsWidth) @ (self bottom - self offset - (0 - minValue * pixelsPerUnit)) - self topLeft / self extent * 1.0

To keep it updated this would have to be hooked up everywhere the number line can change its size. And (maybe) something should be done in case the 0 point is not visible.

Cheers,
Richo


Thanks,
Stephen

_______________________________________________
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
Reply | Threaded
Open this post in threaded view
|

Re: x-y plane questions

Ricardo Moran
I think this could be a useful usage of the "transform" tiles I proposed a while back and never sit down to implement. You could change the rotation center to the 0 point a lot more easily and all within Etoys (without Smalltalk code).
I'll try to make the tiles today even if it's too late to include them in the release.

Cheers,
Richo


On Sun, Mar 18, 2012 at 4:30 PM, Ricardo Moran <[hidden email]> wrote:


On Sun, Mar 18, 2012 at 10:12 AM, Steve Thomas <[hidden email]> wrote:
Scott,

I started looking at the code and was able to change the tick mark width's for the number lines and playing with the marksWidth/marksHeight.
Part of the issue I was having was that the GraphPaper's line width was 1, but the mark's with was 2, so there was no way to center them.
See samples below:
Inline image 1

But I couldn't figure out how to change the pixel width of the graph paper, could you point me in the right direction, thanks.
Also any hints on how can I set the rotational center of the number line to its "0" point?  I can do it with Etoys tiles, But need hints on where would I modify the code and figure out the zero point.

Hi Steve,

I think you can change the rotation center to its 0 point by evaluating this:

For horizontal number lines:
self rotationCenter: ((self left + self offset + (0 - minValue * pixelsPerUnit)) @ (self top + self marksHeight)) - self topLeft / self extent * 1.0
 
For vertical number lines:
self rotationCenter: (self left + self legendsWidth) @ (self bottom - self offset - (0 - minValue * pixelsPerUnit)) - self topLeft / self extent * 1.0

To keep it updated this would have to be hooked up everywhere the number line can change its size. And (maybe) something should be done in case the 0 point is not visible.

Cheers,
Richo


Thanks,
Stephen

_______________________________________________
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
Reply | Threaded
Open this post in threaded view
|

Re: x-y plane questions

Scott Wallace
In reply to this post by Steve Thomas
On Mar 18, 2012, at 6:12 AM, Steve Thomas wrote:

> But I couldn't figure out how to change the pixel width of the graph paper, could you point me in the right direction, thanks



Hi, Steve,

Open the attached fileout in a change-list browser (click "changes" button in file-list); the diffs that will show between the versions in the fileout and what's in the image will answer your question :)  In the versions I've sent, the grid-line-width is parameterized instead of constant, and in both cases, for illustration, that grid-line-width parameter is set to 2.

If wider-than-single-pixel grid lines seem viable and useful and don't introduce new issues (need to be sure to test everything with "scale to fit" turned on), perhaps we could add the grid-line-width as another parameter in the graph-paper panel.

With scale-to-fit on, it seems that with both 1-pixel and 2-pixel grid-line widths we end up with round-off phenomenon such that some of the grid lines are thicker than others.  I'm not sure if this is an intractable mathematical consequence or something fixable, but I suspect that it's the former.

  -- Scott



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

gridLineWidth-sw.1.cs.gz (1K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: x-y plane questions

Ricardo Moran
Hi, 

I made a couple of changes to the number lines that I would like you to check:
* I added two tiles: "transform to pixel" and "transform to graph" (the names could be improved but I didn't know how to name them). This tiles take a number as a parameter and return it transformed to the other coordinate system. It's a general way of using the number lines and I think it could be very useful.
* I changed "x on graph" and "y on graph" to take into account the object's rotation center. However, I could have messed up with this and it could have undesired side effects, so testing would be needed.

I attached a project that uses the x-y plane for ploting bars (open it on Etoys 5.0 beta 2).

Cheers,
Richo

P.S. I just found the "attached watcher" option and it's great!

On Sun, Mar 18, 2012 at 6:16 PM, Scott Wallace <[hidden email]> wrote:
On Mar 18, 2012, at 6:12 AM, Steve Thomas wrote:

> But I couldn't figure out how to change the pixel width of the graph paper, could you point me in the right direction, thanks



Hi, Steve,

Open the attached fileout in a change-list browser (click "changes" button in file-list); the diffs that will show between the versions in the fileout and what's in the image will answer your question :)  In the versions I've sent, the grid-line-width is parameterized instead of constant, and in both cases, for illustration, that grid-line-width parameter is set to 2.

If wider-than-single-pixel grid lines seem viable and useful and don't introduce new issues (need to be sure to test everything with "scale to fit" turned on), perhaps we could add the grid-line-width as another parameter in the graph-paper panel.

With scale-to-fit on, it seems that with both 1-pixel and 2-pixel grid-line widths we end up with round-off phenomenon such that some of the grid lines are thicker than others.  I'm not sure if this is an intractable mathematical consequence or something fixable, but I suspect that it's the former.

 -- Scott



_______________________________________________
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
Reply | Threaded
Open this post in threaded view
|

Re: x-y plane questions

Ricardo Moran
I forgot the project in the previous mail :P.

Richo

On Sun, Mar 18, 2012 at 9:52 PM, Ricardo Moran <[hidden email]> wrote:
Hi, 

I made a couple of changes to the number lines that I would like you to check:
* I added two tiles: "transform to pixel" and "transform to graph" (the names could be improved but I didn't know how to name them). This tiles take a number as a parameter and return it transformed to the other coordinate system. It's a general way of using the number lines and I think it could be very useful.
* I changed "x on graph" and "y on graph" to take into account the object's rotation center. However, I could have messed up with this and it could have undesired side effects, so testing would be needed.

I attached a project that uses the x-y plane for ploting bars (open it on Etoys 5.0 beta 2).

Cheers,
Richo

P.S. I just found the "attached watcher" option and it's great!

On Sun, Mar 18, 2012 at 6:16 PM, Scott Wallace <[hidden email]> wrote:
On Mar 18, 2012, at 6:12 AM, Steve Thomas wrote:

> But I couldn't figure out how to change the pixel width of the graph paper, could you point me in the right direction, thanks



Hi, Steve,

Open the attached fileout in a change-list browser (click "changes" button in file-list); the diffs that will show between the versions in the fileout and what's in the image will answer your question :)  In the versions I've sent, the grid-line-width is parameterized instead of constant, and in both cases, for illustration, that grid-line-width parameter is set to 2.

If wider-than-single-pixel grid lines seem viable and useful and don't introduce new issues (need to be sure to test everything with "scale to fit" turned on), perhaps we could add the grid-line-width as another parameter in the graph-paper panel.

With scale-to-fit on, it seems that with both 1-pixel and 2-pixel grid-line widths we end up with round-off phenomenon such that some of the grid lines are thicker than others.  I'm not sure if this is an intractable mathematical consequence or something fixable, but I suspect that it's the former.

 -- Scott



_______________________________________________
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

BarGraph.001.pr (131K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: x-y plane questions

Scott Wallace
In reply to this post by Ricardo Moran
On Mar 18, 2012, at 5:52 PM, Ricardo Moran wrote:

> I made a couple of changes to the number lines that I would like you to check:

I've looked quickly tonight and hope to have more time tomorrow, but a quick reply for now, hoping others will chime in soon.


> * I added two tiles: "transform to pixel" and "transform to graph" (the names could be improved but I didn't know how to name them). This tiles take a number as a parameter and return it transformed to the other coordinate system. It's a general way of using the number lines and I think it could be very useful.

This certainly expands the bounds of what can be done with number-lines.  Cool example too :)

Since "transform to pixel" provides a transformation from a number-line-based coordinate to a coordinate in the cartesian system of the surrounding Playfield, perhaps it could be called "transform to playfield"?  Not sure if that's much better, if at all, however.

If we adopt these new guys, we'll need to provide balloon help of course...


> * I changed "x on graph" and "y on graph" to take into account the object's rotation center. However, I could have messed up with this and it could have undesired side effects, so testing would be needed.

Oh, good idea!  Thank you!

Good stuff!  The irrepressible Richo - what an asset to the community!


  -- Scott
_______________________________________________
etoys-dev mailing list
[hidden email]
http://lists.squeakland.org/mailman/listinfo/etoys-dev
Reply | Threaded
Open this post in threaded view
|

Re: x-y plane questions

Ricardo Moran

On Mon, Mar 19, 2012 at 3:38 AM, Scott Wallace <[hidden email]> wrote:
On Mar 18, 2012, at 5:52 PM, Ricardo Moran wrote:

> I made a couple of changes to the number lines that I would like you to check:

I've looked quickly tonight and hope to have more time tomorrow, but a quick reply for now, hoping others will chime in soon. 

Great, thanks!
 

> * I added two tiles: "transform to pixel" and "transform to graph" (the names could be improved but I didn't know how to name them). This tiles take a number as a parameter and return it transformed to the other coordinate system. It's a general way of using the number lines and I think it could be very useful.

This certainly expands the bounds of what can be done with number-lines.  Cool example too :)

Yes, I wanted to do it since one of the first versions of the number lines, but it wasn't until I attempted to implement the "ask" tile that I learned how to make these "function" tiles, which are not well supported IMHO.
 

Since "transform to pixel" provides a transformation from a number-line-based coordinate to a coordinate in the cartesian system of the surrounding Playfield, perhaps it could be called "transform to playfield"?  Not sure if that's much better, if at all, however.

If the "transform to graph" is an acceptable name, then maybe we could use "transform from graph" to represent the opposite operation (which is a little better than "transform to pixel" that doesn't mean anything). But naming is a very difficult task and not being a native english speaker doesn't help much...
 
If we adopt these new guys, we'll need to provide balloon help of course...

Yes, of course. Being a lazy person I almost never write them and then I put my native language as an excuse :)
 

> * I changed "x on graph" and "y on graph" to take into account the object's rotation center. However, I could have messed up with this and it could have undesired side effects, so testing would be needed.

Oh, good idea!  Thank you!

Good stuff!  The irrepressible Richo - what an asset to the community!

:)

Cheers,
Richo
 


 -- Scott


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