On Tue, Oct 11, 2011 at 1:59 PM, Randy Caton <rcaton@cnu.edu> wrote:
I like the spreadsheet that Ricardo created because it is simple and basic and allows I/O. It leaves more for learners to create.

I too like the fact that my spreadsheet it's really simple (although I don't really like my implementation) but if we are thinking of including a table like object, I'm pretty sure Skeleton is the right choice. The only disadvantage I can see is the lack of a scroll bar to manage big amounts of data. I'm thinking this could be solved with a ScrollPane object acting as a playfield where you could drop big objects and use the scrollbars to move around. I tried to do it today but I don't understand how the ScrollPane works exactly.
 
Couldn't the functions already in etoys be used in the cells? Does Skeleton allow plots? If so, then what about Ricardo's graphs? I'd like to see them in etoys also. 

I don't know if Skeletong allows plots, but as Karl said, it should be possible to build them with it. As for my graphs, IIRC there were a few technical issues preventing them to be included, but I'll see what I can do this weekend to fix them.

Cheers,
Richo
 

Randy

Randall Caton
41596 Bald Eagle Drive
Bigfork, MN 56628
218-832-3490
Sent from my iPhone

On Oct 11, 2011, at 11:41 AM, Ricardo Moran <richi.moran@gmail.com> wrote:


On Tue, Oct 11, 2011 at 11:20 AM, Bert Freudenberg <bert@freudenbergs.de> wrote:

On 11.10.2011, at 14:34, Ricardo Moran wrote:

> Hi,
>
> The squeak list is currently discussing about a spreadsheet morph, and that just reminded me about how cool is Skeleton actually. So I'm wondering why it is not in Etoys? I found an old discussion stating that it could be a nice extension to Etoys but the biggest issue being the slow loading of external code. I have to agree with that being a problem but I think we might reconsider just include it in the image as with Dr Geo.
>
> I know we already have a bloated image full of half finished projects but from what I briefly tested Skeleton seems to work out of the box. And it doesn't add a *huge* amount of new code. See this simple comparison with DrGeo:
>
> (PackageInfo named: 'Skeleton') systemCategories size. 2
> (PackageInfo named: 'Skeleton') classes size. 38
> (PackageInfo named: 'Skeleton') methods size. 654
> (PackageInfo named: 'Skeleton') linesOfCode. 4765
>
> (PackageInfo named: 'DrGeoII') systemCategories size. 10
> (PackageInfo named: 'DrGeoII') classes size. 214
> (PackageInfo named: 'DrGeoII') methods size.  1863
> (PackageInfo named: 'DrGeoII') linesOfCode.  17154
>
> Another issue, I guess, is that if Skeleton gets included someone will have to maintain it, but from what I've seen the latest version dates from 2006 and it still works today. So maybe it won't be that big of an issue.
>
> Anyway, if you want to test it: http://www.languagegame.org:8080/ggame/11.
>
> Cheers,
> Richo

How does it compare to the data table thing you did in your GSoC project?

My data table serves the only purpose of importing/exporting CSV files, but not much else, whereas Skeleton is a proper spreadsheet, it supports functions, and is well integrated with etoys via drag and drop of tiles.

 
Would be nice to have only one, not two table-like objects.

I agree, but since my table is not integrated anyway, I vote for integrating Skeleton which is much better than what I did. And if we want the I/O of csv files, I could find the way of adapting Skeleton. It shouldn't be that difficult, I suppose.

Cheers,
Richo
 

- Bert -


_______________________________________________
squeakland mailing list
squeakland@squeakland.org
http://lists.squeakland.org/mailman/listinfo/squeakland

_______________________________________________
squeakland mailing list
squeakland@squeakland.org
http://lists.squeakland.org/mailman/listinfo/squeakland