graphing and watching enhancements

I've been working on three somewhat related updates for the new release. The attached zip contains the latest versions of all three, which are expected to be loaded in this order:

numberLines-Richo-sw
       Number lines, which can be used as cuisinaire rods, graph axes, etc.

followingWatcher-sw
       Watchers that behave as if attached to their observees, following them around on the screen

graphPaper-sw
       Adds a graph-paper fill style, with a live editor for tuning its parameters


-----

A "Graphing" category is added to the Objects tool, offering number lines, graph paper, and a prebuilt cartesian plane.  (There are a few more things I was intending to put in this category, but they're not ready so may not make it out this round.)

For graphing, though an "x-y plane" is provided as an example, I think it's best to encourage kids to build their own cartesian plane:  start with a plain "playfield", or plain "graph" paper, and then drop Horizontal and Vertical axes into the playfield, and configure the axes to have the scale and appearance desired, and use the graph-paper panel to make compatible "graph paper" to use with the axes.

Use any "morph" (object) as plot points -- a small Ellipse or Star works well.

If there are horizontal and vertical axes present in a playfield used as a graph, they define the metric by which cartesian coordinates called "xOnGraph" and "yOnGraph" are reckoned.  Look in the "graphing" category of a Viewer for these.

Shift-click on the cyan "open-viewer" icon of any plot point to get an "attached" watcher showing the current "on graph" coordinates of the object.

A Number Line can be configured using items found at the bottom of its halo menu.  But a much more efficient way to configure a number line is by using its Viewer -- look in the "number line" category.

Any playfield can be given a fill style of "graph paper" from the "fill style" item of its halo menu.  A special "graph paper" property sheet allows you to configure grid spacing, tick-mark and legend spacing, and colors of paper and grid.

CAUTION:  If you change the metrics of a number line used as an axis in a playfield showing graph paper, it can easily happen that the grid of the graph paper and the scale of the axes will become out of synch. The user will need to adjust both the graph-paper and the axes so that they match up well together.

Some of this work is still not 100% percent satisfactory, but in view of the need to freeze and test, I put them out now for your scrutiny and comments, and if Karl, Richo, and/or Bert deems it suitable, perhaps one of you can "resolve" them and push them to the repository...

(all these change-sets have also been posted to the tracker.)

 -- Scott


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

Scott,

Thanks for your efforts.  Couple of comments:

• NumberLine: When I change a number lines pixels per unit, its xOnGraph (or yOnGraph) becomes !=0.
• x-y Plane: Also I realize I can build this using tiles, but can we have the objects on the graph have there xOnGraph and yOnGraph stay the same when we change the number lines unitsPerMark?  Hmmm perhaps would be best to simply provide a project that does this, not sure.  FYI, I basically wanted to create a x-y plane the kids could easily scale.
• Graph Paper: I like the sliders to change <coarse grid> and <grid size> in the dialog. But for us older folks whose eyes are starting to age, you may want to change the color scheme. At first I didn't even notice them and thought, wow it would be great if we had sliders or those number changing arrows.  The I eventually found them.
• Graph Paper: To facilitate comparison, in the GraphPaperPanel, could/should we have a button to <revert> so that I can change my (colors, grid size/coarseness, Offset) and click a button to switch back and forth between the original and my new settings?
• Graph Paper: Not exactly sure what Offset does.
• Graph Paper: Can't change the transparency in the Graph Paper Panel
• Graph Paper: The color category in the viewer has all 0 values, and once you change the color using the Viewer, the Graph Paper Panel becomes inaccesible (ie: change color in viewer, then click on eye dropper in Halo)

Stephen

On Thu, Mar 1, 2012 at 6:49 AM, Scott Wallace <[hidden email]> wrote:

I've been working on three somewhat related updates for the new release. The attached zip contains the latest versions of all three, which are expected to be loaded in this order:

numberLines-Richo-sw
       Number lines, which can be used as cuisinaire rods, graph axes, etc.

followingWatcher-sw
       Watchers that behave as if attached to their observees, following them around on the screen

graphPaper-sw
       Adds a graph-paper fill style, with a live editor for tuning its parameters


-----

A "Graphing" category is added to the Objects tool, offering number lines, graph paper, and a prebuilt cartesian plane.  (There are a few more things I was intending to put in this category, but they're not ready so may not make it out this round.)

For graphing, though an "x-y plane" is provided as an example, I think it's best to encourage kids to build their own cartesian plane:  start with a plain "playfield", or plain "graph" paper, and then drop Horizontal and Vertical axes into the playfield, and configure the axes to have the scale and appearance desired, and use the graph-paper panel to make compatible "graph paper" to use with the axes.

Use any "morph" (object) as plot points -- a small Ellipse or Star works well.

If there are horizontal and vertical axes present in a playfield used as a graph, they define the metric by which cartesian coordinates called "xOnGraph" and "yOnGraph" are reckoned.  Look in the "graphing" category of a Viewer for these.

Shift-click on the cyan "open-viewer" icon of any plot point to get an "attached" watcher showing the current "on graph" coordinates of the object.

A Number Line can be configured using items found at the bottom of its halo menu.  But a much more efficient way to configure a number line is by using its Viewer -- look in the "number line" category.

Any playfield can be given a fill style of "graph paper" from the "fill style" item of its halo menu.  A special "graph paper" property sheet allows you to configure grid spacing, tick-mark and legend spacing, and colors of paper and grid.

CAUTION:  If you change the metrics of a number line used as an axis in a playfield showing graph paper, it can easily happen that the grid of the graph paper and the scale of the axes will become out of synch. The user will need to adjust both the graph-paper and the axes so that they match up well together.

Some of this work is still not 100% percent satisfactory, but in view of the need to freeze and test, I put them out now for your scrutiny and comments, and if Karl, Richo, and/or Bert deems it suitable, perhaps one of you can "resolve" them and push them to the repository...

(all these change-sets have also been posted to the tracker.)

 -- Scott

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

Now that Karl has made the graph-paper "offset" better-behaved, I've backed out of the code that had blocked the offset control when coarse-grid was in effect; that's the only difference between the attached version of "graphingFixes-sw" and the one sent out yesterday.





On Mar 4, 2012, at 2:08 PM, Steve Thomas wrote:

> So IF I understand Offset correctly it is the offset of the grid from the origin, yes?
> The interface is very "Bret Victorish" (without the visible sliders).  But it would be nice to be able to enter the #'s as getting to 0@0, can be a pain.

Yes, a digital readout (or two) for the offset would be good…  The "offset" interface right now simply uses the long-standing property-sheet UI for setting point-valued variables, such as the "origin" and "direction" of a gradient fill.   [Meanwhile, a useful hint is:  to get the offset set to 0@0, position the mouse cursor at the top-left corner of the "offset" box.]


> Also why is Offset off, when coarse grid is on?

In yesterday's version, I disabled the Offset when coarse-grid was in effect because I had been unable to get it to work satisfactorily.  In the attached fileout, I've re-enabled it, given Karl's fix.


> Also,  let me know how to get this fix so I can test.
> A .cs or update code from server when ready is best.

Update-from-server (including loading latest updates from the "default repository") will bring in Karl's offset fix.  Then file in the attached (unless/until it also comes in via the update stream.)

 -- Scott


> On Sun, Mar 4, 2012 at 6:54 PM, karl ramberg <[hidden email]> wrote:
> I fixed a issue with the coarse grid not behaving with offset. I had to find the proper starting point in the count variable and things worked fine.
>
> Karl
>
>
> twoTierGridFormOrigin: origin grid: smallGrid  background: backColor line: lineColor darkerGridEvery: darkerGridEvery darkerGridColor: darkerGridColor
>       "Answer an infinite form that repeats a pattern involving grid lines with darker ones at regular intervals, such as 'engineering paper'."
>
>       | smallGridAsPoint gridForm gridOrigin fullGrid aColor darkGridOrigin countX countY |
>       smallGridAsPoint := smallGrid rounded asPoint.
>       fullGrid := smallGridAsPoint * darkerGridEvery.
>       gridForm := Form extent: fullGrid depth: Display depth.
>       gridOrigin := origin \\ smallGridAsPoint.
>       darkGridOrigin := origin \\ fullGrid.
>       backColor ifNotNil: [gridForm fillWithColor: backColor].
>       darkGridOrigin ifNotNil:[countX:=  darkGridOrigin x. countY:=  darkGridOrigin y]
>       ifNil:[countX:= countY := -1].
>
>       gridOrigin x to: gridForm width by: smallGridAsPoint x do:
>               [:x |
>                       aColor := (countX \\ darkerGridEvery) = 0 ifTrue: [darkerGridColor] ifFalse: [lineColor].
>                       gridForm fill: (x@0 extent: 1@gridForm height) fillColor: aColor.
>                       countX:= countX+ 1.].
>       gridOrigin y to: gridForm height by: smallGridAsPoint y do:
>               [:y |
>                       aColor := (countY\\ darkerGridEvery) = 0 ifTrue: [darkerGridColor] ifFalse: [lineColor].
>                       gridForm fill: (0@y extent: gridForm width@1) fillColor: aColor.
>                       countY:= countY+ 1.].
>       ^ InfiniteForm with: gridForm
>
> "
>       | aPlayfield |
>       aPlayfield := PasteUpMorph authoringPrototype extent: 640 @ 480.
>       aPlayfield color: (GraphPaperParameters twoTierGridFormOrigin: (0@0) grid: 16 background: Color green muchLighter line: Color blue muchLighter darkerGridEvery: 10 darkerGridColor: Color blue muchDarker).
>       aPlayfield openInHand
> "
>
>
> On Sun, Mar 4, 2012 at 10:20 PM, Scott Wallace <[hidden email]> wrote:
> On Mar 3, 2012, at 5:54 AM, karl ramberg wrote:
>
> > ...Yes, all the stuff will be included. I fixed a couple of issues with graph paper and will add the rest over the weekend.
>
> Thank you, Karl!
>
> Attached now is a fileout that responds to all the issues and recommendations relating to the graphing tools that have appeared in the past few days, and cleans up a few loose ends.  Its preamble:
>
> Change Set:             graphingFixes-sw
> Date:                   4 March 2012
> Author:                 Scott Wallace
>
> Addresses various bug-reports and recommendations relating to recent number-line and graph-paper updates:
> - Enforce reasonable ranges for the sliders governing the grid parameters, taking the grid-size, coarse-grid-size , and playfield dimensions into account.
> - Provide a button to request 'graph paper' from the 'generic property sheet' when appropriate.
> - Retain position of number line when its pixelsPerUnit changes.
> - Disable the 'offset' when coarse-grid in effect.
> - Protect sliders against zero-divide that can happen if minVal = maxVal.
> - Protect InfiniteForms against incidental calls to #darker and #twiceDarker that can be sent to any object's fillStyle by some of the custom border code.
> - Removes about a dozen superfluous methods that had mistakenly lingered in the earlier updates, and removes three inst vars of NumberLineMorph that were remnants from earlier code….
>
> -----------
>
> Sorry this was just a little too late to make it into update 2398, but hopefully these cleanups can get pushed out soon; it wouldn't be good for users to start using the graphing tools before these fixes are in.
>
> Thanks again!
>
>  -- 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

Thanks Scott

I added this to the update stream.

I think we have all the stuff in now.

I will try to get a beta image out as soon as possible so we can get it tested.

Karl

On Mon, Mar 5, 2012 at 8:14 PM, Scott Wallace <[hidden email]> wrote:

Now that Karl has made the graph-paper "offset" better-behaved, I've backed out of the code that had blocked the offset control when coarse-grid was in effect; that's the only difference between the attached version of "graphingFixes-sw" and the one sent out yesterday.

On Mar 4, 2012, at 2:08 PM, Steve Thomas wrote:

> So IF I understand Offset correctly it is the offset of the grid from the origin, yes?
> The interface is very "Bret Victorish" (without the visible sliders).  But it would be nice to be able to enter the #'s as getting to 0@0, can be a pain.

Yes, a digital readout (or two) for the offset would be good…  The "offset" interface right now simply uses the long-standing property-sheet UI for setting point-valued variables, such as the "origin" and "direction" of a gradient fill.   [Meanwhile, a useful hint is:  to get the offset set to 0@0, position the mouse cursor at the top-left corner of the "offset" box.]


> Also why is Offset off, when coarse grid is on?

In yesterday's version, I disabled the Offset when coarse-grid was in effect because I had been unable to get it to work satisfactorily.  In the attached fileout, I've re-enabled it, given Karl's fix.

> Also,  let me know how to get this fix so I can test.
> A .cs or update code from server when ready is best.

Update-from-server (including loading latest updates from the "default repository") will bring in Karl's offset fix.  Then file in the attached (unless/until it also comes in via the update stream.)

 -- Scott

> On Sun, Mar 4, 2012 at 6:54 PM, karl ramberg <[hidden email]> wrote:
> I fixed a issue with the coarse grid not behaving with offset. I had to find the proper starting point in the count variable and things worked fine.
>
> Karl
>
>
> twoTierGridFormOrigin: origin grid: smallGrid  background: backColor line: lineColor darkerGridEvery: darkerGridEvery darkerGridColor: darkerGridColor
>       "Answer an infinite form that repeats a pattern involving grid lines with darker ones at regular intervals, such as 'engineering paper'."
>
>       | smallGridAsPoint gridForm gridOrigin fullGrid aColor darkGridOrigin countX countY |
>       smallGridAsPoint := smallGrid rounded asPoint.
>       fullGrid := smallGridAsPoint * darkerGridEvery.
>       gridForm := Form extent: fullGrid depth: Display depth.
>       gridOrigin := origin \\ smallGridAsPoint.
>       darkGridOrigin := origin \\ fullGrid.
>       backColor ifNotNil: [gridForm fillWithColor: backColor].
>       darkGridOrigin ifNotNil:[countX:=  darkGridOrigin x. countY:=  darkGridOrigin y]
>       ifNil:[countX:= countY := -1].
>
>       gridOrigin x to: gridForm width by: smallGridAsPoint x do:
>               [:x |
>                       aColor := (countX \\ darkerGridEvery) = 0 ifTrue: [darkerGridColor] ifFalse: [lineColor].
>                       gridForm fill: (x@0 extent: 1@gridForm height) fillColor: aColor.
>                       countX:= countX+ 1.].
>       gridOrigin y to: gridForm height by: smallGridAsPoint y do:
>               [:y |
>                       aColor := (countY\\ darkerGridEvery) = 0 ifTrue: [darkerGridColor] ifFalse: [lineColor].
>                       gridForm fill: (0@y extent: gridForm width@1) fillColor: aColor.
>                       countY:= countY+ 1.].
>       ^ InfiniteForm with: gridForm
>
> "
>       | aPlayfield |
>       aPlayfield := PasteUpMorph authoringPrototype extent: 640 @ 480.
>       aPlayfield color: (GraphPaperParameters twoTierGridFormOrigin: (0@0) grid: 16 background: Color green muchLighter line: Color blue muchLighter darkerGridEvery: 10 darkerGridColor: Color blue muchDarker).
>       aPlayfield openInHand
> "
>
>
> On Sun, Mar 4, 2012 at 10:20 PM, Scott Wallace <[hidden email]> wrote:
> On Mar 3, 2012, at 5:54 AM, karl ramberg wrote:
>
> > ...Yes, all the stuff will be included. I fixed a couple of issues with graph paper and will add the rest over the weekend.
>
> Thank you, Karl!
>
> Attached now is a fileout that responds to all the issues and recommendations relating to the graphing tools that have appeared in the past few days, and cleans up a few loose ends.  Its preamble:
>
> Change Set:             graphingFixes-sw
> Date:                   4 March 2012
> Author:                 Scott Wallace
>
> Addresses various bug-reports and recommendations relating to recent number-line and graph-paper updates:
> - Enforce reasonable ranges for the sliders governing the grid parameters, taking the grid-size, coarse-grid-size , and playfield dimensions into account.
> - Provide a button to request 'graph paper' from the 'generic property sheet' when appropriate.
> - Retain position of number line when its pixelsPerUnit changes.
> - Disable the 'offset' when coarse-grid in effect.
> - Protect sliders against zero-divide that can happen if minVal = maxVal.
> - Protect InfiniteForms against incidental calls to #darker and #twiceDarker that can be sent to any object's fillStyle by some of the custom border code.
> - Removes about a dozen superfluous methods that had mistakenly lingered in the earlier updates, and removes three inst vars of NumberLineMorph that were remnants from earlier code….
>
> -----------
>
> Sorry this was just a little too late to make it into update 2398, but hopefully these cleanups can get pushed out soon; it wouldn't be good for users to start using the graphing tools before these fixes are in.
>
> Thanks again!
>
>  -- 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

Now that Karl has made the graph-paper "offset" better-behaved, I've backed out of the code that had blocked the offset control when coarse-grid was in effect; that's the only difference between the attached version of "graphingFixes-sw" and the one sent out yesterday.





On Mar 4, 2012, at 2:08 PM, Steve Thomas wrote:

> So IF I understand Offset correctly it is the offset of the grid from the origin, yes?
> The interface is very "Bret Victorish" (without the visible sliders).  But it would be nice to be able to enter the #'s as getting to 0@0, can be a pain.

Yes, a digital readout (or two) for the offset would be good…  The "offset" interface right now simply uses the long-standing property-sheet UI for setting point-valued variables, such as the "origin" and "direction" of a gradient fill.   [Meanwhile, a useful hint is:  to get the offset set to 0@0, position the mouse cursor at the top-left corner of the "offset" box.]


> Also why is Offset off, when coarse grid is on?

In yesterday's version, I disabled the Offset when coarse-grid was in effect because I had been unable to get it to work satisfactorily.  In the attached fileout, I've re-enabled it, given Karl's fix.


> Also,  let me know how to get this fix so I can test.
> A .cs or update code from server when ready is best.

Update-from-server (including loading latest updates from the "default repository") will bring in Karl's offset fix.  Then file in the attached (unless/until it also comes in via the update stream.)

 -- Scott


> On Sun, Mar 4, 2012 at 6:54 PM, karl ramberg <[hidden email]> wrote:
> I fixed a issue with the coarse grid not behaving with offset. I had to find the proper starting point in the count variable and things worked fine.
>
> Karl
>
>
> twoTierGridFormOrigin: origin grid: smallGrid  background: backColor line: lineColor darkerGridEvery: darkerGridEvery darkerGridColor: darkerGridColor
>       "Answer an infinite form that repeats a pattern involving grid lines with darker ones at regular intervals, such as 'engineering paper'."
>
>       | smallGridAsPoint gridForm gridOrigin fullGrid aColor darkGridOrigin countX countY |
>       smallGridAsPoint := smallGrid rounded asPoint.
>       fullGrid := smallGridAsPoint * darkerGridEvery.
>       gridForm := Form extent: fullGrid depth: Display depth.
>       gridOrigin := origin \\ smallGridAsPoint.
>       darkGridOrigin := origin \\ fullGrid.
>       backColor ifNotNil: [gridForm fillWithColor: backColor].
>       darkGridOrigin ifNotNil:[countX:=  darkGridOrigin x. countY:=  darkGridOrigin y]
>       ifNil:[countX:= countY := -1].
>
>       gridOrigin x to: gridForm width by: smallGridAsPoint x do:
>               [:x |
>                       aColor := (countX \\ darkerGridEvery) = 0 ifTrue: [darkerGridColor] ifFalse: [lineColor].
>                       gridForm fill: (x@0 extent: 1@gridForm height) fillColor: aColor.
>                       countX:= countX+ 1.].
>       gridOrigin y to: gridForm height by: smallGridAsPoint y do:
>               [:y |
>                       aColor := (countY\\ darkerGridEvery) = 0 ifTrue: [darkerGridColor] ifFalse: [lineColor].
>                       gridForm fill: (0@y extent: gridForm width@1) fillColor: aColor.
>                       countY:= countY+ 1.].
>       ^ InfiniteForm with: gridForm
>
> "
>       | aPlayfield |
>       aPlayfield := PasteUpMorph authoringPrototype extent: 640 @ 480.
>       aPlayfield color: (GraphPaperParameters twoTierGridFormOrigin: (0@0) grid: 16 background: Color green muchLighter line: Color blue muchLighter darkerGridEvery: 10 darkerGridColor: Color blue muchDarker).
>       aPlayfield openInHand
> "
>
>
> On Sun, Mar 4, 2012 at 10:20 PM, Scott Wallace <[hidden email]> wrote:
> On Mar 3, 2012, at 5:54 AM, karl ramberg wrote:
>
> > ...Yes, all the stuff will be included. I fixed a couple of issues with graph paper and will add the rest over the weekend.
>
> Thank you, Karl!
>
> Attached now is a fileout that responds to all the issues and recommendations relating to the graphing tools that have appeared in the past few days, and cleans up a few loose ends.  Its preamble:
>
> Change Set:             graphingFixes-sw
> Date:                   4 March 2012
> Author:                 Scott Wallace
>
> Addresses various bug-reports and recommendations relating to recent number-line and graph-paper updates:
> - Enforce reasonable ranges for the sliders governing the grid parameters, taking the grid-size, coarse-grid-size , and playfield dimensions into account.
> - Provide a button to request 'graph paper' from the 'generic property sheet' when appropriate.
> - Retain position of number line when its pixelsPerUnit changes.
> - Disable the 'offset' when coarse-grid in effect.
> - Protect sliders against zero-divide that can happen if minVal = maxVal.
> - Protect InfiniteForms against incidental calls to #darker and #twiceDarker that can be sent to any object's fillStyle by some of the custom border code.
> - Removes about a dozen superfluous methods that had mistakenly lingered in the earlier updates, and removes three inst vars of NumberLineMorph that were remnants from earlier code….
>
> -----------
>
> Sorry this was just a little too late to make it into update 2398, but hopefully these cleanups can get pushed out soon; it wouldn't be good for users to start using the graphing tools before these fixes are in.
>
> Thanks again!
>
>  -- 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

Scott,

Some issues with latest build:

1. Take x-y plane from Object Catalog, Open Viewer for "vertical number line", change number lines <min val> to -10, then increase by 1 to -9.  (number line shifts left).
2. If Number Lines <min val> is greater than zero, its not really a "show negative arrow head" tile. Not sure of good name.
3. If I set <VerticalNumberLine's>:<yOnGraph> to 0, it changes to 8 and moves down. This behavior repeats. It seems to be 8 when min value <=-10 and 4 when >-10.
4. Perhaps related to the above items: I would expect the <xOnGraph> and <yOnGraph> to be 0, but they are not.  Perhaps because of how you adjust for the labels and the max # of digits in the label.  Perhaps have the "0" point on the number line be 0@0 onGraph.  I was also struck that the playfield does not use origin at center, but there is much I do not understand.
5. When I turn "use gridding" from the playfield options, I need to reset the the "grid spacing" to match that set via the GraphPaperPanel.
6. Should we have Etoys tiles for the grid size, coarse grid boolean and course grid value?  I know I can get them by opening the viewer for the sliders and firing the EtoysUpdatingThreePhaseButton, but most folks won't figure that out. 
7. When I delete the x-y plane with the GraphPaperPanel open the panel does not dissapear.
8. Baloon help for Vertical number <show negative arrow head< line states: "Whether to show an arrow-head at the extreme left edge of the axis".  Perhaps "lower end" instead.
9. It would be nice to have tiles for the offset and the numbers visible, without having to hover.

Last note: I am in Argentina two weeks and other than a chance to visit Ricardo, I generally don't like travelling especially for so long.  I often say, and my boss likes to remind me, the reward for work well done is the opportunity to do more.  So I often struggle with how good of a job to do (well not really, I always try to do my best).

So Scott, hopefully you are not feeling the same way with all my comments, your efforts are greatly appreciated.

Thanks,

Stephen

On Mon, Mar 5, 2012 at 4:14 PM, Scott Wallace <[hidden email]> wrote:

Now that Karl has made the graph-paper "offset" better-behaved, I've backed out of the code that had blocked the offset control when coarse-grid was in effect; that's the only difference between the attached version of "graphingFixes-sw" and the one sent out yesterday.

On Mar 4, 2012, at 2:08 PM, Steve Thomas wrote:

> So IF I understand Offset correctly it is the offset of the grid from the origin, yes?
> The interface is very "Bret Victorish" (without the visible sliders).  But it would be nice to be able to enter the #'s as getting to 0@0, can be a pain.

Yes, a digital readout (or two) for the offset would be good…  The "offset" interface right now simply uses the long-standing property-sheet UI for setting point-valued variables, such as the "origin" and "direction" of a gradient fill.   [Meanwhile, a useful hint is:  to get the offset set to 0@0, position the mouse cursor at the top-left corner of the "offset" box.]


> Also why is Offset off, when coarse grid is on?

In yesterday's version, I disabled the Offset when coarse-grid was in effect because I had been unable to get it to work satisfactorily.  In the attached fileout, I've re-enabled it, given Karl's fix.

> Also,  let me know how to get this fix so I can test.
> A .cs or update code from server when ready is best.

Update-from-server (including loading latest updates from the "default repository") will bring in Karl's offset fix.  Then file in the attached (unless/until it also comes in via the update stream.)

 -- Scott

> On Sun, Mar 4, 2012 at 6:54 PM, karl ramberg <[hidden email]> wrote:
> I fixed a issue with the coarse grid not behaving with offset. I had to find the proper starting point in the count variable and things worked fine.
>
> Karl
>
>
> twoTierGridFormOrigin: origin grid: smallGrid  background: backColor line: lineColor darkerGridEvery: darkerGridEvery darkerGridColor: darkerGridColor
>       "Answer an infinite form that repeats a pattern involving grid lines with darker ones at regular intervals, such as 'engineering paper'."
>
>       | smallGridAsPoint gridForm gridOrigin fullGrid aColor darkGridOrigin countX countY |
>       smallGridAsPoint := smallGrid rounded asPoint.
>       fullGrid := smallGridAsPoint * darkerGridEvery.
>       gridForm := Form extent: fullGrid depth: Display depth.
>       gridOrigin := origin \\ smallGridAsPoint.
>       darkGridOrigin := origin \\ fullGrid.
>       backColor ifNotNil: [gridForm fillWithColor: backColor].
>       darkGridOrigin ifNotNil:[countX:=  darkGridOrigin x. countY:=  darkGridOrigin y]
>       ifNil:[countX:= countY := -1].
>
>       gridOrigin x to: gridForm width by: smallGridAsPoint x do:
>               [:x |
>                       aColor := (countX \\ darkerGridEvery) = 0 ifTrue: [darkerGridColor] ifFalse: [lineColor].
>                       gridForm fill: (x@0 extent: 1@gridForm height) fillColor: aColor.
>                       countX:= countX+ 1.].
>       gridOrigin y to: gridForm height by: smallGridAsPoint y do:
>               [:y |
>                       aColor := (countY\\ darkerGridEvery) = 0 ifTrue: [darkerGridColor] ifFalse: [lineColor].
>                       gridForm fill: (0@y extent: gridForm width@1) fillColor: aColor.
>                       countY:= countY+ 1.].
>       ^ InfiniteForm with: gridForm
>
> "
>       | aPlayfield |
>       aPlayfield := PasteUpMorph authoringPrototype extent: 640 @ 480.
>       aPlayfield color: (GraphPaperParameters twoTierGridFormOrigin: (0@0) grid: 16 background: Color green muchLighter line: Color blue muchLighter darkerGridEvery: 10 darkerGridColor: Color blue muchDarker).
>       aPlayfield openInHand
> "
>
>
> On Sun, Mar 4, 2012 at 10:20 PM, Scott Wallace <[hidden email]> wrote:
> On Mar 3, 2012, at 5:54 AM, karl ramberg wrote:
>
> > ...Yes, all the stuff will be included. I fixed a couple of issues with graph paper and will add the rest over the weekend.
>
> Thank you, Karl!
>
> Attached now is a fileout that responds to all the issues and recommendations relating to the graphing tools that have appeared in the past few days, and cleans up a few loose ends.  Its preamble:
>
> Change Set:             graphingFixes-sw
> Date:                   4 March 2012
> Author:                 Scott Wallace
>
> Addresses various bug-reports and recommendations relating to recent number-line and graph-paper updates:
> - Enforce reasonable ranges for the sliders governing the grid parameters, taking the grid-size, coarse-grid-size , and playfield dimensions into account.
> - Provide a button to request 'graph paper' from the 'generic property sheet' when appropriate.
> - Retain position of number line when its pixelsPerUnit changes.
> - Disable the 'offset' when coarse-grid in effect.
> - Protect sliders against zero-divide that can happen if minVal = maxVal.
> - Protect InfiniteForms against incidental calls to #darker and #twiceDarker that can be sent to any object's fillStyle by some of the custom border code.
> - Removes about a dozen superfluous methods that had mistakenly lingered in the earlier updates, and removes three inst vars of NumberLineMorph that were remnants from earlier code….
>
> -----------
>
> Sorry this was just a little too late to make it into update 2398, but hopefully these cleanups can get pushed out soon; it wouldn't be good for users to start using the graphing tools before these fixes are in.
>
> Thanks again!
>
>  -- 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

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