[etoys-dev] [squeakland] Charts (was: New Graphing Tools)
richi.moran at gmail.com
Mon Oct 17 10:59:57 EDT 2011
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
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
> Each scale could have reference to a collection of "points/things to
> 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.
>>> - 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
> I like the preference, with the default set to negative off.
>>> 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
>>>> 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.
>>>> P.S. I also renamed the project to Charts as Bert suggested
>>>> squeakland mailing list
>>>> squeakland at squeakland.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the etoys-dev