[squeakland] Charts (was: New Graphing Tools)

[Ricardo Moran]

On Mon, Oct 17, 2011 at 11:25 AM, Steve Thomas <sthomas1 at gosargon.com>wrote:

> On Mon, Oct 17, 2011 at 9:48 AM, Ricardo Moran <richi.moran at gmail.com>wrote:
>
>> Hi Steve, thanks for your feedback :)
>>
> I would think you have learned by now not to encourage me :)
>

:)


 Understood (well at least at the imagining how things are
> designed/implemented level).  The only concern I have is if you don't do it
> this way how can you (or can you) have an objects forward by, move based on
> scale settings instead of pixels?
>

Yes, I know what you're saying. Right now you would have to move it by
changing it's x and y. I don't really know how you can make "forward" work
with this approach, though.

Hmmmm...  Perhaps (warning requirement overload potential)  You could have a
> move item in collection forward by tile (read further and hopefully what I
> am suggesting will become clear, not necessarily the right thing to do, but
> clear).
>

At first glance, it doesn't sound right to me, with that tile the viewer
might occupy half the screen! :)


>
> Let's say you have a scale (or pair of scales).  My thinking is along these
> lines...
> Each scale could have  reference to a collection of "points/things to
> graph"
> Then when you either:
>
>    - change a scale, or
>    - add a "point" to the referenced collection,
>
> you then:
>
>    - For each object in the collection:
>    - change the point(s) X,Y to match the scale
>
> The use case I am thinking of is kids plot a bunch of points, then you
> change the scale, you would want the points to auto-magically adjust to the
> new scale setting.
>

Well, then we go back to the first versions of the graphing tools, remember?
Where you had a PointGraph containing its own "coordinate system" and a
collection of "points". I feel perfectly fine with that approach but IIRC it
was decided that these tools were too specific, and all you really need to
build a graph is a pair of number lines.

Richo


>
>>>    - Perhaps have an option to show 0 (or not).  This would be useful
>>>    for when you have two axis that intersect at 0, as it would look better if
>>>    we didn't show the 0 labels.
>>>
>>> Yes, that's something I thought too.
>>
>>
>>>
>>>    - When I change the *Line's min val* it changes the max value (and
>>>    vica versa).  Hmmm, okay I think I'm beginning to understand why you did
>>>    this.  I was used to setting the min and max value for the axis and having
>>>    the scale adjust as opposed to the scale setting the max value (well "Invert
>>>    always invert" ;)  Have to think about this.
>>>
>>> Mmm... I don't remember why I did it like that. I guess I thought the
>> scale was more important and it should be fixed, but I can change that if
>> you feel it should be the other way around.
>>
>>>
>>>    - The labels seem a little too close to the number lines.
>>>
>>> True. I'll fix that.
>>
>>
>>>
>>>    - It would be nice to have tiles to specify the font and size for the
>>>    labels. (Or course it would be nice to tiles to specify font, size,
>>>    centered/left flush|right flush|centered, for all text objects :)
>>>
>>> Mmm... I could add those tiles to the text objects but I'm not sure of
>> adding them to the number line. Maybe I could add the "collections" category
>> to the number lines and you could iterate over its submorphs changing
>> whatever property you like. In fact, I think that could be added to all
>> objects because all of them can behave like a collection. What do you think?
>>
>>>
>>>    - How can you set the arrow head for the negative direction?
>>>
>>> Well, you can't :). But that's easy to fix. I don't remember who did but
>> someone told me that the axis with the two arrow heads was confusing because
>> it is supposed to point to the direction of positive infinity, but I always
>> thought the arrows represent the axis going on forever, so I removed the
>> negative arrow head at the time. I don't really know what is the correct
>> meaning of the arrow heads but I could add a preference to turn the negative
>> on/off.
>>
> I like the preference, with the default set to negative off.
>
>>
>> Cheers,
>> Richo
>>
>>
>>
>>> Stephen
>>>
>>> On Sun, Oct 16, 2011 at 8:16 PM, Ricardo Moran <richi.moran at gmail.com>wrote:
>>>
>>>> Hi guys, I'm trying again with the graphing tools. It's been a while
>>>> since I worked on this (sorry about that) but I really want to see them
>>>> integrated.
>>>>
>>>> So now I'm following Bert's suggestions and I'm trying with a less
>>>> general approach: I'm not introducing a new scale on top of the existing
>>>> one, instead I just added a "current object" slot on the number lines, and a
>>>> "current object position in chart" slot that transforms from squeak's pixel
>>>> to the number line scale and viceversa.
>>>>
>>>> The implementation is much simpler than before but it's more
>>>> uncomfortable IMHO. I think it would be best to have two "transform"
>>>> functions accepting a number as argument and returning it transformed from
>>>> one scale to the other. Unfortunately, it seems Etoys doesn't support this
>>>> kind of functions nicely, all the examples I could find (such as
>>>> #color:sees:) seem to be a little hacked and I wasn't sure if following that
>>>> path was the right way to proceed.
>>>>
>>>> I think the best would be for you to test it and tell me what you think.
>>>> I'm attaching a project with the new number lines.
>>>> Thanks!
>>>>
>>>> Richo
>>>>
>>>> P.S. I also renamed the project to Charts as Bert suggested
>>>>
>>>> _______________________________________________
>>>> squeakland mailing list
>>>> squeakland at squeakland.org
>>>> http://lists.squeakland.org/mailman/listinfo/squeakland
>>>>
>>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakland.org/pipermail/squeakland/attachments/20111017/dcd442c6/attachment.html>