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: [image: 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
On Sun, Mar 18, 2012 at 10:12 AM, Steve Thomas sthomas1@gosargon.comwrote:
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: [image: 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 etoys-dev@squeakland.org http://lists.squeakland.org/mailman/listinfo/etoys-dev
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 richi.moran@gmail.comwrote:
On Sun, Mar 18, 2012 at 10:12 AM, Steve Thomas sthomas1@gosargon.comwrote:
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: [image: 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 etoys-dev@squeakland.org http://lists.squeakland.org/mailman/listinfo/etoys-dev
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
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 <scott.wallace@squeakland.org
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 etoys-dev@squeakland.org http://lists.squeakland.org/mailman/listinfo/etoys-dev
I forgot the project in the previous mail :P.
Richo
On Sun, Mar 18, 2012 at 9:52 PM, Ricardo Moran richi.moran@gmail.comwrote:
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 < scott.wallace@squeakland.org> 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 etoys-dev@squeakland.org http://lists.squeakland.org/mailman/listinfo/etoys-dev
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
On Mon, Mar 19, 2012 at 3:38 AM, Scott Wallace <scott.wallace@squeakland.org
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@lists.squeakfoundation.org
-
Ricardo Moran -
Scott Wallace -
Steve Thomas