<br><div class="gmail_quote">On Mon, Aug 16, 2010 at 2:29 AM, Steve Thomas <span dir="ltr">&lt;<a href="mailto:sthomas1@gosargon.com">sthomas1@gosargon.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">

Ricardo,<div><br></div><div>Thanks, don&#39;t worry too much about the ballon help for now, I can provide a first draft of wording later if it helps.</div></blockquote><div><br></div><div>That would be great. I&#39;ll write something as well. I don&#39;t think it&#39;s too much work and if I keep cleaning these tools there would be even less.</div>

<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div><br></div><div>Also I got a good laugh when I opened your project, the visuals are great ;)</div></blockquote>

<div><br></div><div>Haha :)</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div><br></div><div>In the Tables, the &quot;remove row&quot; seems to only remove the last row, which means I can&#39;t remove a row in the middle. One way to deal with this would be to have it remove the row at &quot;row index&quot;.</div>


<div><br></div><div>Your &quot;<b>row</b> first&quot; and &quot;<b>row</b> second&quot; seem to have the values of the first and second <b>column</b> of the &quot;row index&quot; <b>row</b>. This also limits you to only two columns for the table implementation. I think a more general solution could meet the need.</div>

</blockquote><div><br></div><div>Maybe we can adapt the Spreadsheet object for this stuff. We need to think of a way of linking rows or columns with axes but it could be done I think.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">


<div><br></div><div>A couple of points on the &quot;point graph&quot;:</div><div><ol><li>You can only plot one set of points (I tried opening a second point table from the menu, but the items simply moved no new items were added.</li>

</ol></div></blockquote><div>If we manage to adapt the spreadsheet object this won&#39;t be a problem anymore. </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div>
<ol>
<li>If I add additional objects to the graph (for example I may want to add some descriptive text or items that are not to be used as &quot;displayable points&quot;, when I click apply they disappear.</li></ol></div></blockquote>

<div>As it is now, any object dropped into the graph becomes a point (except for the axes, labels, grids and stuff, which are building parts of the graph). Maybe we could ask the user every time he drops an object whether he wants to use it as a point or not. I don&#39;t really like this solution. Other idea would be to never use texts as points. Or maybe add an option to the object&#39;s menu that will allow it behave as a point or not. I don&#39;t know... I&#39;m just throwing some ideas...</div>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div><ol><li>Not sure how you added the objects to use as &quot;points&quot; unless through collections</li></ol></div>

</blockquote><div>I don&#39;t really understand what you mean, sorry. </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div><ol>
<li>I added a point (using &quot;add point&quot; in the &quot;plot points&quot; category and it was placed at 0,0, then when I moved the point I accidentally moved the arrow that was the axis line.</li></ol></div></blockquote>

<div>Maybe I could lock the building parts of the graph. That would avoid this happening. </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div><ol><li>The ability to plot lines would be nice. </li>

</ol></div></blockquote><div>Yes, it would. Maybe we could make different object behave as points or lines or segments or vectors... When dropping the object, the graph would then distinguish each case... I don&#39;t know. Maybe Lines behave like lines/segments, Arrows as vectors, Ellipses/Sketches could be points. In any case, I think this would complicate things a little. Maybe Dr. Geo is the right tool for that kind of stuff.</div>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div><ol>
</ol><div>In general a lot of clever stuff, I especially like your latest addition of being able to define your own &quot;point graphics&quot;.  You could do a <a href="http://www.youtube.com/watch?v=hVimVzgtD6w" target="_blank">Hans Rosling Gapminer style graphs</a> with this type of approach, (although we should make sure the kids don&#39;t try sword swallowing ;)  This would be a good Etoys project a great way to show change over time and facilitate appropriate comparisons and help determine causality. This project could actually be done now with Etoys 4.</div>

</div></blockquote><div><br></div><div>Wow, I really liked Hans Rosling graphs. I didn&#39;t know about them and I think we&#39;re getting closer to his approach.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">

<div>
<div><br></div><div>I feel there are too many categories for the graph (that said I am not sure how to reduce them, I have been looking at other implementations of graphs (Excel, Open Office {which has chart junk that makes Excel look good, etc) to get ideas. Numbers from iWork has the interface elements I like best so far.</div>

</div></blockquote><div><br></div><div>I too believe so. We could make a new object like a properties panel which would change the graphs properties, but it wouldn&#39;t be scriptable and I don&#39;t really like this idea neither.</div>

<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div>
<div><br></div><div>All that said I still really feel all we need for the graph is:</div><div><ul><li>a Number line object</li></ul></div></div></blockquote><div>I think this is a very good idea. I haven&#39;t built it this way but now I think I should. This number line could be used for so many other thinks like time lines and stuff like that. IIRC there used to be a timeline object in Etoys (I couldn&#39;t find it though). This could be useful for teaching history I guess (I know of an uruguayan teacher who would use such object).</div>

<div>Also, building graphs composing this objects would help decrease the amount of viewer categories of the graph because the range, the legend spacing, colors, etc. would be a part of the number line.</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">

<div><div><ul><li>a way to change the scaling of X and Y in a playfield (ie: 1 unit = 20 pixels, with perhaps different units in X and Y to allow logarithimic graphs.)</li>
<ul><li>This could have other uses, I have seen a similar implementation of this in the UNCW version of STEM Etoys.</li></ul></ul></div></div></blockquote><div>I think Playfields are already very complex objects. I don&#39;t know how much work this would take but it would be a great addition.</div>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div><div><ul><li>a way to have the gridding start at an offset from the bottom left corner of the playfield (to allow for a cleaner looking single quadrant chart)</li>

</ul></div></div></blockquote><div>Again a good addition, which I don&#39;t know yet how to implement :)</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div><div>

<ul>
</ul><div>Then the table could be holder with the following new features:</div><div><ul><li>fixed width row and column sizes</li><li>the ability to address a particular row and column (yes the kids could do the math, but I think this is one of the things that should be easy)</li>

</ul></div></div></div></blockquote><div>I keep thinking the best object for this would be the Spreadsheet.</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div>

<div><div><ul>
</ul><div>The Number line you almost have complete (hash marks would be a nice addition).</div><div>Scaling of movement in a playfield should be trivial (if the code is well designed ;)</div><div>Changing gridding don&#39;t know, but doing it with a pen trails is simple enough.</div>

</div></div></div></blockquote><div><br></div><div>I will look into this, I think they are all great ideas.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">

<div><div><div><div>Making a table using a holder would be relatively easy with scripting tiles, by using fixed size text boxes or Holders and whatever you want. </div><div>You could even have a column for the point graphic (which could be  player variable, or a graphic scaled to the standard row/column size) for example:</div>


</div></div></div><blockquote style="margin:0 0 0 40px;border:none;padding:0px">X, Y, Object to use as Point<br>1, 2   &lt;Star graphic&gt;<br>2, 20 &lt;graphic 2&gt;<br>...</blockquote>
<div><div><div><div><br></div></div></div></div></blockquote><div><br></div><div>One great idea of the Skeleton spreadsheet was letting the user link a cell&#39;s value with a viewer tile by dropping it inside the cell. We could make the Spreadsheet object work like that or see if Skeleton could be integrated in Etoys. I like it even though I think it&#39;s a very big and complex tool.</div>

<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div><div><div><div></div><div><br></div><div>You could plot the number of useful code changes over time using Day as the X axis and the other values along the Y axis with a table like this:</div>

<div><br></div></div>
</div></div><blockquote style="margin:0 0 0 40px;border:none;padding:0px">Day  Richo   Stephen  Bert<br> 1        1            0         2   <br> 2        3            0         4<br>
 3        5            0         6</blockquote><div><div><div><div><br></div><div>In fact if we just had a just number line kids could develop their own graphing tools (which if there was an easy way to package up and re-use what you create, hint hint nudge nudge wink wink)  would be a great thing for kids to do. Imagine kids making their own tools!! They might evolve (of course after spending most of their free time playing &quot;Call of Duty&quot; and the like, they would probably create weapons to kill people). But of course games don&#39;t have any influence on kids behavior, that&#39;s why we are wasting our time at things like &quot;Games for Change&quot; and &quot;Games for Learning&quot;.</div>

</div></div></div></blockquote><div><br></div><div>Yes! Let the kids built their own tools. It would be great!</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">

<div><div><div>
<div><br></div><div>Hey wait a minute!!!! Richo&#39;s Morph I/O could be used by kids as a way to package their own tools!!!!  Good job RIcho.</div></div></div></div></blockquote><div><br></div><div>:)</div><div><br></div>

<div>Thanks for your comments Steve! I think the graphing tools will become much nicer with all these ideas :D</div><div>Richo </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">

<div><div><div><div><br></div><div><br></div></div></div></div><div>Stephen<div><div></div><div class="h5"><br><br><div class="gmail_quote">
On Sun, Aug 15, 2010 at 11:38 PM, Ricardo Moran <span dir="ltr">&lt;<a href="mailto:richi.moran@gmail.com" target="_blank">richi.moran@gmail.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">


I think you&#39;re going to like this version :) <a href="http://tecnodacta.com.ar/gira/gsoc/NewGraphingTools.002.pr" target="_blank">http://tecnodacta.com.ar/gira/gsoc/NewGraphingTools.002.pr</a><div><br></div><div>I still haven&#39;t done all the things you told me but I&#39;m getting there. I finally removed the PointMorph and BarMorph classes. Everything works as before but you can use now any object as a Point or Bar, you just drop it on the graph and it gets added to the point/bar list (well... almost any object, I guess there might be problems with some complex morphs...)</div>




<div><br></div><div>In the case of the bars, I used the object&#39;s height as its value and the object&#39;s name as its label, like you suggested. Also, the objects you add to a graph get a new viewer category for its specific slots. I haven&#39;t done the same for vectors yet but I will do it soon. As I&#39;m thinking it, we will have three different graphs for bars, points, and vectors. That&#39;s the easiest way I found to distinguish each drop correctly.</div>




<div><br></div><div>I also merged the PointTableMorph and BarTableMorph classes into TableOfValuesMorph, and I merged a few short viewer categories. What I haven&#39;t done yet is writing the balloon helps and using the holder vocabulary for the graphs but I wanted to show this at least, which I think it&#39;s much nicer than what I had before. Please comment if you think this is the right direction. Thanks!</div>




<div><br></div><div>Richo</div><div><br></div><div><br><div class="gmail_quote"><div><div></div><div>On Sat, Aug 14, 2010 at 8:58 PM, Bert Freudenberg <span dir="ltr">&lt;<a href="mailto:bert@freudenbergs.de" target="_blank">bert@freudenbergs.de</a>&gt;</span> wrote:<br>




</div></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div></div><div><div style="word-wrap:break-word"><div><div><div></div><div><div>On 15.08.2010, at 00:37, Ricardo Moran wrote:</div>




<br><blockquote type="cite">On Sat, Aug 14, 2010 at 4:15 PM, Bert Freudenberg <span dir="ltr">&lt;<a href="mailto:bert@freudenbergs.de" target="_blank">bert@freudenbergs.de</a>&gt;</span> wrote:<br><div class="gmail_quote">




<blockquote class="gmail_quote" style="margin-top:0px;margin-right:0px;margin-bottom:0px;margin-left:0.8ex;border-left-width:1px;border-left-color:rgb(204, 204, 204);border-left-style:solid;padding-left:1ex">

<div><br>
On 14.08.2010, at 19:00, Ricardo Moran wrote:<br>
<br>
&gt; Hi, I&#39;ve just uploaded a new commit to the inbox. It contains all the graphing tools and speech bubbles with most of Bert&#39;s suggestions fixed. I&#39;m sorry for the big commit but I moved my older commits to treated because they were incomplete. Now the only commits needed to have these tools working properly are: Morphic-Richo.33 and Etoys-Richo.32<br>







&gt; I hope they got accepted into Etoys. I&#39;m excited :)<br>
<br>
</div>I think they will :) I cleaned out the inbox today, merged all submissions, made minor modifications.<br>
<br>
I only did not merge Etoys-Richo.32 yet. It is much nicer than the previous version, but still not quite there IMHO:<br>
<br>
* the &quot;remove&quot; tile duplicates the existing &quot;erase&quot; tile<br>
* barColor duplicates color<br>
* a lot of graph tiles duplicate holder functionality<br>
* a &quot;bar table&quot; is something in a club ;) I think calling it &quot;table of values&quot; would be better<br>
* privateExtent:/privateCenter:/privatePosition: methods duplicate the existing extent:/center:/position: methods<br>
* there is still a reference to Vector (though only in an example method)<br>
* there already is another object called &quot;Graph&quot; in the object catalog<br>
* none of the new slots have a balloon help<br>
* some of the &quot;plot - ...&quot; categories are quite short, they should be merged<br>
* apply, max, min, remove, are all a bit short. There is already minVal/maxVal and getMinVal/getMaxVal for example which you could reuse<br>
<br>
I think the apparent complexity could be simplified when adopting more of the holder vocabulary. Instead of &quot;index&quot; call it &quot;cursor&quot;. &quot;point x&quot; would be &quot;x value at cursor&quot; or so. Etc.<br>






</blockquote><div><br></div><div>Most of these can be fixed easily. Specially the terminology ones (I didn&#39;t know about the &quot;bar table&quot;, otherwise I would have used other term :P)</div><div> </div><blockquote class="gmail_quote" style="margin-top:0px;margin-right:0px;margin-bottom:0px;margin-left:0.8ex;border-left-width:1px;border-left-color:rgb(204, 204, 204);border-left-style:solid;padding-left:1ex">




Ideally, the graph would just *be* a holder/playfield. E.g. in a bar graph, the user might just put plain rectangles or sketches or whatever. Instead of extra labels, use the rectangle&#39;s name. The value would simply be calculated from the object&#39;s width and the bar scale factor (just like you did for points, which can be moved freely - cool). Same for xy graphs - the points could be *any* object in a playfield. And possibly even points and vectors could be unified - a point would just be a vector of length 0? That might be not the best idea, I don&#39;t know. How much more time do you have in your project?<br>






</blockquote><div><br></div><div>So adding a bar/point/vector would be just dropping an object (any object) into the graph... I like it, I think it&#39;s possibly a good idea (if we manage to figure out a nice way of unifying vectors and points... maybe different graphs for each?), but it&#39;s quite different from what I currently have and I&#39;m not sure I&#39;ll be able to make it in time for this release. Since this seems like a big change I think adding these tools to the Etoys release may not be such a good idea. Maybe we should wait to hear the opinion of the educators about this change and if they like it, work on this for the next release.</div>






<div><br></div><div>The GSoC deadline is this monday and I didn&#39;t even finish the seven items in my proposal. I will still work on this after gsoc is over but I worked very little in the PaintBox and I haven&#39;t even touched the EtoyMaker. That&#39;s a bummer...</div>






<div> </div><blockquote class="gmail_quote" style="margin-top:0px;margin-right:0px;margin-bottom:0px;margin-left:0.8ex;border-left-width:1px;border-left-color:rgb(204, 204, 204);border-left-style:solid;padding-left:1ex">





<br>
I have no serious complaints about the bubble implementation (except for the empty help balloons on the tiles), but you submitted both together so I could not merge them yet.<br></blockquote><div><br></div><div>I&#39;ll write the balloon help and I&#39;ll push the bubbles to Etoys myself, if that&#39;s ok with you.</div>






</div></blockquote><div><br></div></div></div>Certainly.</div><br><font color="#888888"><div>
<span style="border-collapse:separate;border-spacing:0px 0px;color:rgb(0, 0, 0);font-family:Lucida Grande;font-size:12px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;line-height:normal;text-align:auto;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><div style="font-family:Helvetica">




<span style="font-family:Helvetica">- Bert -</span></div><br></span>
</div>
<br></font></div><br></div></div><div>_______________________________________________<br>
etoys-dev mailing list<br>
<a href="mailto:etoys-dev@squeakland.org" target="_blank">etoys-dev@squeakland.org</a><br>
<a href="http://lists.squeakland.org/mailman/listinfo/etoys-dev" target="_blank">http://lists.squeakland.org/mailman/listinfo/etoys-dev</a><br>
<br></div></blockquote></div><br></div>
<br>_______________________________________________<br>
etoys-dev mailing list<br>
<a href="mailto:etoys-dev@squeakland.org" target="_blank">etoys-dev@squeakland.org</a><br>
<a href="http://lists.squeakland.org/mailman/listinfo/etoys-dev" target="_blank">http://lists.squeakland.org/mailman/listinfo/etoys-dev</a><br>
<br></blockquote></div><br></div></div></div>
</blockquote></div><br>