etoys-dev October 2011

etoys-dev@lists.squeakfoundation.org

18 participants
75 discussions

Re: [etoys-dev] Stencils in Etoys
by Steve Thomas 02 Dec '11

02 Dec '11

Subbu, Thanks this is a lot of fun and useful. So I tried to use it for fractions (although I really like your art work project at Ofset <http://community.ofset.org/index.php/Grab_area_button>better, but I am thinking about fractions lately) I used the "do menu item | stencil a sketch" scripting tile in a "Mouse Down" script. The rectangle then moves forward by its width. So with a series of successive clicks you can make a fraction. It get's my vote for inclusion in the next release. Thanks, Stephen On Fri, Jul 22, 2011 at 10:02 PM, K. K. Subramaniam <kksubbu.ml(a)gmail.com>wrote: > Hi Steve, > > I have attached a patch to Morphic that adds three functions to 'extras...' > menu for any Morph. These enable anyone to quick convert an assembly of > morphs > into a sketch (e.g. a car assembled using rectangles and ellipses), use any > morph as a stencil to cut out a sketch from underlying screen area and to > create silhouette (shadow) sketch respectively. > > To use the patch, just drop it into Etoys and select "file it in". I would > appreciate it if you could use it and let me know if it is useful. If so, I > will send it to Etoys Inbox. > > Subbu >

3 12

About Skeleton
by Ricardo Moran 04 Nov '11

04 Nov '11

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

11 32

Re: [etoys-dev] [squeakland] Kids using images and scripting
by karl ramberg 31 Oct '11

31 Oct '11

On Mon, Oct 31, 2011 at 6:40 PM, Kim Rose <kim.rose(a)vpri.org> wrote: > Hello, > > A quick bit of history and a reminder: > > Etoys was developed with the idea that the children would create *their own* > art -- to encourage drawing and not just cut/pasting other people's > clip-art. We'd love to see that encouraged although we realize there are > "powerful forces" working against us. Children have little self-esteem > regarding their drawing skills; they need encouragement, praise and > practice. > > Additionally, the original intent of Etoys was not to enable/encourage all > kids to be "programmers" but to get children to think more scientifically, > and less superstitiously, and in a more thoughtful manner all together when > thinking about the world we inhabit and how it works. > > Kim Rose I agree with much of this. But we must help the kids by showing them a way. Many kids will just give up as it's too much to discover and its to hard to do by them self. What I think is way forward is to help kids make the stuff they want. Tutorials and specially youtube clips showing how to make the kind of images they like will encourage them to make it them self. Art is hard and it's not obvious how to make it. Lot's of tricks and tools are used and it take some dedication. Etoys paint tools are good for most cases but can be a little crude and unforgiving. Crude by having only round and big brushes. And the very hard pixelated edges makes detail work hard. Non obvious color palette memory. There is no zoom to do details. Unforgiving in the sense that editing instances take time getting used to. You edit the original! You must remember to keep a copy or you lose your work ! Karl > > Viewpoints Research is a 501(c)(3) nonprofit organization dedicated to > improving "powerful ideas education" for the world's children and advancing > the state of systems research and personal computing. Please visit us online > at www.vpri.org > > > > > > On Oct 31, 2011, at 10:06 AM, Steve Thomas wrote: > >> Changed subject from previous emails. >> On Mon, Oct 31, 2011 at 11:12 AM, Bert Freudenberg <bert(a)freudenbergs.de> >> wrote: >> On 31.10.2011, at 03:09, Ricardo Moran wrote: >> >> > Some kids told me they would want more graphics to choose in Etoys (like >> > the ones in Scratch). >> >> Why don't they use images they found on the web, or took using a camera? >> >> So I see a couple of issues: >> • Should we include a predefined set of images similar to Scratch? >> • Why don't kids use images found on web or took using a camera? >> • How can we get kids scripting (as opposed to just "playing with >> images" and creating cartoons) >> On item 1: Should we include a predefined set of images similar to >> Scratch? >> The argument I have heard against including images is that kids that: >> "Seeing graphics that they might not be able to create themselves easily >> can discourage them from make their own paintings." >> >> If that is the case, then why do are there so many kid created graphics in >> Scratch projects? I have, on admittedly limited evidence, seen kids getting >> stuck drawing, because they feel they can't draw well enough, which >> slows/stops them. >> >> On item 2: Why don't kids use images found on web or took using a camera? >> Good question, once I show kids that this can be done, they do it. So >> perhaps it is an issue of "discoverability"? >> There is a quick guide on Objects/Digital Images which is XO specific. But >> does not indicate how to import an image from the Web on XO. >> Also, the switching to journal/copy to clipboard, ... may be too many >> steps, which might discourage kids. >> >> On item 3: How can we get kids scripting, modeling, simulating (as >> opposed to just "playing with images" and creating cartoons) >> Great question, need to think about this some more. Not that playing with >> images, creating cartoons and using Etoys as a PowerPoint replacement are >> bad things, but how do we get them scripting, modeling, simulating as well. >> >> Stephen >> _______________________________________________ >> squeakland mailing list >> squeakland(a)squeakland.org >> http://lists.squeakland.org/mailman/listinfo/squeakland > > > _______________________________________________ > Squeakland mailing list > Squeakland(a)squeakland.org > http://lists.squeakland.org/mailman/listinfo/squeakland >

1 0

Kids using images and scripting
by Steve Thomas 31 Oct '11

31 Oct '11

Changed subject from previous emails. On Mon, Oct 31, 2011 at 11:12 AM, Bert Freudenberg <bert(a)freudenbergs.de>wrote: > On 31.10.2011, at 03:09, Ricardo Moran wrote: > > > Some kids told me they would want more graphics to choose in Etoys (like > the ones in Scratch). > > Why don't they use images they found on the web, or took using a camera? So I see a couple of issues: 1. Should we include a predefined set of images similar to Scratch? 2. Why don't kids use images found on web or took using a camera? 3. How can we get kids scripting (as opposed to just "playing with images" and creating cartoons) *On item 1*: Should we include a predefined set of images similar to Scratch? The argument I have heard against including images is that kids that: "Seeing graphics that they might not be able to create themselves easily can discourage them from make their own paintings." If that is the case, then why do are there so many kid created graphics in Scratch projects? I have, on admittedly limited evidence, seen kids getting stuck drawing, because they feel they can't draw well enough, which slows/stops them. *On item 2:* Why don't kids use images found on web or took using a camera? Good question, once I show kids that this can be done, they do it. So perhaps it is an issue of "discoverability"? There is a quick guide on *Objects/Digital Images* which is XO specific. But does not indicate how to import an image from the Web on XO. Also, the switching to journal/copy to clipboard, ... may be too many steps, which might discourage kids. *On item 3:* How can we get kids scripting, modeling, simulating (as opposed to just "playing with images" and creating cartoons) Great question, need to think about this some more. Not that playing with images, creating cartoons and using Etoys as a PowerPoint replacement are bad things, but how do we get them scripting, modeling, simulating as well. Stephen

1 0

Clip art was Re: About Skeleton
by David Corking 31 Oct '11

31 Oct '11

On Mon, Oct 31, 2011 at 3:12 PM, Bert Freudenberg wrote: > Ricardo Moran wrote: > >> Some kids told me they would want more graphics to choose in Etoys (like the ones in Scratch). > > Why don't they use images they found on the web, or took using a camera? I wonder if it is the workflow? On Sugar, the child may need to switch to the Browse activity, save the artwork to the journal, switch back to Etoys, and then import the image. In a windowing environment with a larger screen they can copy-paste or drag and drop. Some kids I worked with a couple of weeks ago used copy-paste like this (though with a proprietary document editor.) It seemed to me that it became a hunt for the coolest image as the overwhelming number of choices in Google Images stifled their creativity. Despite my concerns, the kids really enjoyed making some entertaining collages.

1 0

Re: [etoys-dev] 64 bit Linux VM?
by Steve Thomas 30 Oct '11

30 Oct '11

Sorry meant to reply to dev before. Found one bug, I was able to save a project locally and open the saved project. I was able to login to squeakland, but when I tried to open a project from the squeakland repository got an exception. (See log) Stephen On Sat, Oct 29, 2011 at 3:33 PM, Steve Thomas <sthomas1(a)gosargon.com> wrote: > Unpacked and ran on 64 bit Ubuntu 11.10 and it opened fine and was able to > run simple Kedama script. > > Stephen > > > On Sat, Oct 29, 2011 at 2:18 PM, Yoshiki Ohshima <yoshiki(a)vpri.org> wrote: > >> At Sat, 29 Oct 2011 09:23:18 -0700, >> Yoshiki Ohshima wrote: >> > >> > Hi, >> > >> > Does anybody have, or is willing to make, a Linux VM for the "x86_64" >> > CPU, and possibly include it in the To-Go package? >> > >> > I was asked that To-Go package does not work on such an installation, >> > which is now common. >> >> Just for the heck of it, I compiled a VM for Linux-x86_64. If you >> have such a platform, download >> >> http://tinlizzie.org/~ohshima/Linux-x86_64.tar.gz >> >> and unpack it just to the side of Linux-i686. Let me (and Bert) know >> if it works well or not. >> >> -- Yoshiki >> _______________________________________________ >> etoys-dev mailing list >> etoys-dev(a)squeakland.org >> http://lists.squeakland.org/mailman/listinfo/etoys-dev >> > >

2 1

64 bit Linux VM?
by Yoshiki Ohshima 29 Oct '11

29 Oct '11

Hi, Does anybody have, or is willing to make, a Linux VM for the "x86_64" CPU, and possibly include it in the To-Go package? I was asked that To-Go package does not work on such an installation, which is now common. -- Yoshiki

1 1

Re: [etoys-dev] Etoys: Etoys-kfr.95.mcz
by Bert Freudenberg 27 Oct '11

27 Oct '11

IMHO these should be properties of a SketchMorph. When that property changes, its "rotatedForm" would be recomputed from its "originalForm", taking these properties into account (unless they have their default value). Sort of like independent filters - people rightly should expect this to work similar as in Scratch. Btw, with all these new features I'm getting excited about the 2011 release :) We should name it 4.2, at least. - Bert - On 24.10.2011, at 17:59, commits(a)source.squeak.org wrote: > Karl Ramberg uploaded a new version of Etoys to project Etoys: > http://source.squeak.org/etoys/Etoys-kfr.95.mcz > > ==================== Summary ==================== > > Name: Etoys-kfr.95 > Author: kfr > Time: 24 October 2011, 7:59:23 pm > UUID: 238320d7-b378-a746-892f-c4a910ffa21d > Ancestors: Etoys-bf.94 > > Add blur: brightness: satruation: and hue: to graphics category. Now possible to play a little with picture colors etc. > > =============== Diff against Etoys-bf.94 =============== > > Item was added: > + ----- Method: Player>>blur: (in category '*Etoys-Scratch') ----- > + blur: aWidth > + | f fOut | > + f := self getGraphic asFormOfDepth: 32. > + fOut := f bits copy. > + ScratchPlugin > + primBlur: f bits > + into: fOut > + width: f width + aWidth. > + f bits: fOut. > + self > + setGraphic: (f asFormOfDepth: 16)! > > Item was added: > + ----- Method: Player>>brightness: (in category '*Etoys-Scratch') ----- > + brightness: aNumber > + | f fOut | > + f := self getGraphic asFormOfDepth: 32. > + fOut := f deepCopy. > + ScratchPlugin > + primShiftBrightness: f bits > + into: fOut bits > + by: aNumber. > + self > + setGraphic: (fOut asFormOfDepth: 16)! > > Item was added: > + ----- Method: Player>>hue: (in category '*Etoys-Scratch') ----- > + hue: aDegree > + | f fOut degree | > + degree := aDegree. > + degree > 180 > + ifTrue: [degree := -360 + degree]. > + f := self getGraphic asFormOfDepth: 32. > + fOut := f deepCopy. > + ScratchPlugin > + primShiftHue: f bits > + into: fOut bits > + byDegrees: degree. > + self > + setGraphic: (fOut asFormOfDepth: 16)! > > Item was added: > + ----- Method: Player>>saturation: (in category '*Etoys-Scratch') ----- > + saturation: aNumber > + | f fOut | > + f := self getGraphic asFormOfDepth: 32. > + fOut := f deepCopy. > + ScratchPlugin > + primShiftSaturation: f bits > + into: fOut bits > + by: aNumber. > + self > + setGraphic: (fOut asFormOfDepth: 16)! > > Item was changed: > ----- Method: SketchMorph class>>additionsToViewerCategories (in category '*eToys-scripting') ----- > additionsToViewerCategories > + ^ #(#(#graphics #(#(#slot #graphic 'The picture currently being worn' #Graphic #readWrite #Player #getGraphic #Player #setGraphic:) #(#command #wearCostumeOf: 'wear the costume of...' #Player) #(#slot #baseGraphic 'The picture originally painted for this object, but can subsequently be changed via menu or script' #Graphic #readWrite #Player #getBaseGraphic #Player #setBaseGraphic:) #(#command #restoreBaseGraphic 'Make my picture be the one I remember in my baseGraphic') #(#slot #rotationStyle 'How the picture should change when the heading is modified' #RotationStyle #readWrite #Player #getRotationStyle #Player #setRotationStyle:) #(#command #flipLeftRight 'Flip the picture left to right' #Player) #(#command #flipUpDown 'Flip the picture upside down' #Player) #(#command #blur: 'blur the image...' #Number) #(#command #hue: 'change color hue degree...' #Number) #(#command #brightness: 'change color brightness...' #Number) #(#command #saturation: 'change color saturation...' > #Number))) )! > - "Answer a list of (<categoryName> <list of category specs>) pairs that characterize the phrases this kind of morph wishes to add to various Viewer categories." > - > - ^ #((graphics ( > - (slot graphic 'The picture currently being worn' Graphic readWrite Player getGraphic Player setGraphic:) > - (command wearCostumeOf: 'wear the costume of...' Player) > - (slot baseGraphic 'The picture originally painted for this object, but can subsequently be changed via menu or script' Graphic readWrite Player getBaseGraphic Player setBaseGraphic:) > - (command restoreBaseGraphic 'Make my picture be the one I remember in my baseGraphic') > - > - (slot rotationStyle 'How the picture should change when the heading is modified' RotationStyle readWrite Player getRotationStyle Player setRotationStyle:) > - (command flipLeftRight 'Flip the picture left to right' Player) > - (command flipUpDown 'Flip the picture upside down' Player) > - ))) > - > - > - ! > > _______________________________________________ > etoys-dev mailing list > etoys-dev(a)squeakland.org > http://lists.squeakland.org/mailman/listinfo/etoys-dev

4 17

Etoys: MorphicExtras-kfr.56.mcz
by commits＠source.squeak.org 26 Oct '11

26 Oct '11

Karl Ramberg uploaded a new version of MorphicExtras to project Etoys: http://source.squeak.org/etoys/MorphicExtras-kfr.56.mcz ==================== Summary ==================== Name: MorphicExtras-kfr.56 Author: kfr Time: 26 October 2011, 10:48:12 pm UUID: cf667459-1c1a-b440-bdbe-10a4c4bff729 Ancestors: MorphicExtras-kfr.55 Webcam does not need the get grapics tile =============== Diff against MorphicExtras-kfr.55 =============== Item was changed: ----- Method: WebCamMorph class>>additionsToViewerCategories (in category 'scripting') ----- additionsToViewerCategories "Answer a list of (<categoryName> <list of category specs>) pairs that characterize the phrases this kind of morph wishes to add to various Viewer categories." ^ #( (#'camera' ( (slot resolution '160x120, 320x240 or 640x480' WebCamResolution readWrite Player getWebCamResolution Player setWebCamResolution:) (slot cameraIsOn 'Whether the camera is on/off' Boolean readWrite Player getWebCamIsOn Player setWebCamIsOn:) (slot useFrameSize 'Resize the player to match the cameras frame size' Boolean readWrite Player getUseFrameSize Player setUseFrameSize:) (slot lastFrame 'A player with the last frame' Player readOnly Player getLastFrame unused unused) + )) - (slot graphic 'The picture currently being worn' Graphic readOnly Player getVideoGraphic unused unused) - )) - ) !

1 0

Etoys: OLPC-Display-yo.4.mcz
by commits＠source.squeak.org 25 Oct '11

25 Oct '11

Bert Freudenberg uploaded a new version of OLPC-Display to project Etoys: http://source.squeak.org/etoys/OLPC-Display-yo.4.mcz ==================== Summary ==================== Name: OLPC-Display-yo.4 Author: yo Time: 24 October 2011, 2:23:40 pm UUID: 90f57f12-d88b-4a75-b6b0-09975df4f0e9 Ancestors: OLPC-Display-bf.3 When you are showing 'actual pixels', the zoom goes outside of expected area. =============== Diff against OLPC-Display-bf.3 =============== Item was changed: ----- Method: OLPCVirtualScreen>>zoomIn:orOutTo:at:vanishingPoint: (in category 'transitions') ----- zoomIn: goingIn orOutTo: otherImage at: topLeft vanishingPoint: vp "Make sure we cover the full display here" | otherDisplay otherWarp otherOffset otherScale | pendingUpdate := false. otherDisplay := Form extent: display extent depth: 32. otherDisplay fillColor: (Color gray: 0.2). + otherScale := (otherImage width / otherDisplay width + max: otherImage height / otherDisplay height) max: 1. + - otherScale := otherImage width / otherDisplay width - max: otherImage height / otherDisplay height. otherOffset := otherDisplay extent - (otherImage extent / otherScale) // 2. otherWarp := WarpBlt toForm: otherDisplay. otherWarp sourceForm: otherImage. otherWarp cellSize: 2. otherWarp combinationRule: Form over. otherWarp sourceForm: otherImage destRect: (otherOffset extent: otherImage extent // otherScale). otherWarp warpBits. display zoomIn: goingIn orOutTo: otherDisplay at: 0@0 vanishingPoint: (vp // self displayScale)+self displayOffset. !

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

etoys-dev October 2011