[etoys-dev] graphing and watching enhancements
Ricardo Moran
richi.moran at gmail.com
Mon Mar 5 19:52:33 EST 2012
Hi guys,
I'm currently out of time to help with this because I'm preparing for an
exam next week, but I wanted to say this looks absolutely *awesome*.
I was thinking of adding to the number lines a couple of tiles called
"transform to graph" and "transform to pixel" (or something similar). These
tiles would take a number as a parameter and would return its value
transformed from one coordinate system to the other. So I think they could
be used as a general mechanism for building graphs (for instance, we could
transform the length of a rectangle to build a bar graph). What do you
think?
Cheers,
Richo
On Mon, Mar 5, 2012 at 6:56 PM, Steve Thomas <sthomas1 at gosargon.com> wrote:
> 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 at 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 <
> scott.wallace at squeakland.org> 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 at 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 at 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 <karlramberg at gmail.com>
>> 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 at 0 extent: 1 at 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 at y extent: gridForm width at 1)
>> fillColor: aColor.
>> > countY:= countY+ 1.].
>> > ^ InfiniteForm with: gridForm
>> >
>> > "
>> > | aPlayfield |
>> > aPlayfield := PasteUpMorph authoringPrototype extent: 640 @ 480.
>> > aPlayfield color: (GraphPaperParameters twoTierGridFormOrigin:
>> (0 at 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 <
>> scott.wallace at squeakland.org> 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
>> > etoys-dev at squeakland.org
>> > http://lists.squeakland.org/mailman/listinfo/etoys-dev
>> >
>> >
>>
>>
>> _______________________________________________
>> etoys-dev mailing list
>> etoys-dev at squeakland.org
>> http://lists.squeakland.org/mailman/listinfo/etoys-dev
>>
>>
>
> _______________________________________________
> etoys-dev mailing list
> etoys-dev at squeakland.org
> http://lists.squeakland.org/mailman/listinfo/etoys-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakland.org/pipermail/etoys-dev/attachments/20120305/226b14cc/attachment.html>
More information about the etoys-dev
mailing list