Changes

This page is updated each week (usually on Monday morning) with notes from the Sugar Labs community. (The digest is also sent to the community-news at sugarlabs.org list, blogged at [http://walterbender.org/ walterbender.org], and [[Archive/Current Events|archived here]].) If you would like to contribute, please send email to [[User:walter|walter]] at sugarlabs.org by the weekend. (Also visit <span class="plainlinks">[http://planet.sugarlabs.org planet.sugarlabs.org].</span>)

This page is updated each week (usually on Monday morning) with notes from the Sugar Labs community. (The digest is also sent to the community-news at sugarlabs.org list, blogged at [http://walterbender.org/ walterbender.org], and [[Archive/Current Events|archived here]].) If you would like to contribute, please send email to [[User:walter|walter]] at sugarlabs.org by the weekend. (Also visit <span class="plainlinks">[http://planet.sugarlabs.org planet.sugarlabs.org].</span>)





== Sugar Digest ==

==Sugar Digest==

1. I am working on a modification of Sugar's View Source mechanism that allows the user to make modifications to copies of the source code. So far, I have it working for Sugar activities. It is quite simple actually: I added a palette button to the existing viewsource.py code (written by Tomeu Vizoso) to make a local copy of the activity being viewed. I rename the copy to MyActivity and change the bundle_id to bundle_id_my_copy.

1. I was in Brussels last week to attend TedxKids. I have to admit that I was not very anxious to make yet another trip across the Atlantic Ocean, but I had made a commitment to run a workshop for roughly 50 ten-year-old children, whose parents would be attending the Tedx lectures. (My former colleague at MIT, Dan Ariely has done some nice studies on “time discounting” that explain why is it easy to make such commitments far in advance while dreading them when the actual event is just around the corner.)

It is that simple: one mouse click and you have a copy of any activity available to modify while leaving the original activity intact. And you immediately see a working copy of the activity on your Sugar Home View.

While I was not at all surprised that I would enjoy working with the children—we spent an intense 45 minutes exploring Turtle Blocks—I was very pleasantly surprised at the quality of the program overall. One speaker after another demonstrated some tangible aspect of Constructionist learning (although few actually referred to Papert et al.). The children built sensors, did 3-D printing, build robots, programmed, wrote music, and generally had a blast.

As far as making modifications, at present, I am leaving it to the user to open the Terminal activity and make changes using vi or nano. I am considering enabling either Pippy or the Edit activity to open files in ~/Activities or to expose ~/Activities in the Journal in much the way we are considering for ~/Documents. Feedback would be appreciated.

 

While I was impressed by how far the children got in such a short time, I continue to struggle with how to make the experience of debugging paramount. Too often I have seen children using graphical programming environments just pushing around blocks in a rote manner to achieve some visual effect but with little understanding of how things work such that they can make systemic changes.

 

I was inspired to write a simple Turtle Blocks example that incorporates sensor input in a way that requires little if any calibration, hence it is readily accessible to newbie programmers and gives them lots of places in the code in which they can made meaningful interventions.

 

 

I also wrote [http://git.sugarlabs.org/turtleart/mainline/blobs/master/samples/scratch.ta a simple sample program] (including in Turtle Blocks Version 108) that emulates some basic Scratch functionality in Turtle Blocks: animating a character sprite across a background image. The idea is to reveal the underlying mechanics of a typical Scratch experience. My hope is that it will make less opaque some of the black-box-like operators so popular in Scratch. I still struggle with the question of how to entice teachers and students to embrace programming through simple modifications to the programs they are using, which brings me to the next topic.

 

2. I cleaned up my patches to the Sugar View-source mechanism: (1) Sugar platform source code can be viewed through the same mechanism as Sugar activity code; and (2) the source code can be copied to create an end-user modifiable version of any Sugar activity.

Next up is to do something similar with Sugar itself. I am working on a patch that will provide View Source to Sugar and the Sugar toolkit. (The current version of my patch adds a View Source Button as a menu item under the Journal icon on the Frame.) Once I have this working, adding a copy mechanism, perhaps to ~/site-packages, would be a simple modification. Change sys.path and you are up and running on a locally modifiable version. No root access required!

The Sugar source code simply appears along side the activity source code, under a second radio button on the View Source toolbar.

I have to think through the implications of how the user will switch back and forth between Sugar versions. With activities, since I change the bundle_id, the original and modified versions can coexist. It is not obvious--at least to me--how to have two different versions of Sugar running in parallel. This wouldn't be a problem as long as the user doesn't make a change to Sugar that causes it to crash, but I expect (hope) that will happen frequently. (As Samuel Beckett said: "Ever tried. Ever failed. No matter. Try Again. Fail again. Fail better.") So we need some recovery mechanism that is not dependent on a working Sugar.

The copy function is invoked through a secondary menu available under the activity radio button on the View Source toolbar.

2. In the very cool department: Check out Koji Yokokawa's project that enables you to control Scratch from Etoys (See http://www.squeaksource.com/ScratchConnect.html).

At the suggestion of Ana Cichero and with help from Manuel Quiñones I modify the icon of the local copy of an activity so that it is readily apparent which version is the one to be modified by the end user.

=== In the community ===

I am still a bit up in the air regarding how to best enable the actual modifications. I am considering adding a file chooser to the Edit activity in order to facilitate writeable access to the source directly from Sugar (without having to open the Terminal activity).

3. The New Zealand Testing Team is expanding: Tabitha Roder and Tom Parker are happy to announce the arrival of Oliver Nathan Erasmus Parker, born 17:38 on 6 May (See pictures at http://carrott.org/gingernut/).

My bigger conundrum is in regard to modifying the Sugar platform source. While it is as easy to modify as activity code, the consequences of making a mistake can be dire: Sugar could break in ways that prevent it from launching. One idea I am toying with is adding a prompt on start up to select which version of Sugar to run (from the system or from $HOME). Note: I'd only issue the prompt if a copy of Sugar was found in $HOME.

4. The joint GNOME and KDE 2011 Desktop Summit is taking place in Berlin from August 6–12.

Try out my patches, which were sent to the sugar-devel list. Further feedback would be appreciated.

=== Sugar Labs ===

=== Sugar Labs ===

<gallery>

<gallery>

File:2011-May-14-20-som.jpg|2011 May 14th–29th (74 emails)

File:2011-May-28-Jun-6-som.jpg 2011|May 28th– June 6th (57 emails)

File:2011-May-7-13-som.jpg|2011 May 7th–13th (75 emails)

File:2011-May-21-27-som.jpg 2011|May 21th–27th (34 emails)

</gallery>

</gallery>