Sugar Labs - User contributions [en]

Development Team/Sugargame

2010-06-27T17:34:08Z

Wade: /* Adding Pygame to a PyGTK activity */

== Sugargame ==

Sugargame is a Python package which allows [http://www.pygame.org/ Pygame]
programs to run well under Sugar.
It is fork of the olcpgames framework, which is no longer maintained.

http://git.sugarlabs.org/projects/sugargame

What it does:

* Wraps a Sugar activity around an existing Pygame program with few changes
* Allows Sugar toolbars and other widgets to be added to the activity UI
* Provides hooks for saving to and restoring from the Journal

==== Differences between Sugargame and olpcgames ====

The olpcgames framework provides a wrapper around Pygame which attempts to
allow a Pygame program to run mostly unmodified under Sugar. To this end,
the Pygame program is run in a separate thread with its own Pygame message
loop while the main thread runs the GTK message loop. Also, olpcgames wraps
Sugar APIs such as the journal and mesh into a Pygame-like API.

Sugargame takes a simpler approach; it provides a way to embed Pygame into a
GTK widget. The Sugar APIs are used to interact with Sugar, the Pygame APIs
are used for the game.

Sugargame advantages:

* Simpler code
* More elegant interface between Pygame and GTK
* Runs as a single thread: no thread related segfaults
* Possible to use Sugar widgets with Pygame

Sugargame limitations:

* No support for Pango or SVG sprites (yet)

== Using Sugargame ==

See also [[Development Team/Sugargame/Examples]].

==== Wrapping a Pygame program ====

To use Sugargame to Sugarize a Pygame program, set up an activity directory and
copy the Sugargame package to it.

The activity directory should look something like this:

activity/ - Activity directory: activity.info, SVG icon, etc.
sugargame/ - Sugargame package
MyActivity.py - Activity class
mygame.py - Pygame code
setup.py - Install script

To make the Activity class, start with test/TestActivity.py from the Sugargame
distribution.

The activity should create a single PygameCanvas widget and call run_pygame on it.
Pass the main loop function of the Pygame program.

self._canvas = sugargame.canvas.PygameCanvas(self)
self.set_canvas(self._canvas)

# Start the game running.
self._canvas.run_pygame(self.game.run)

In your Pygame main loop, pump the GTK message loop:

while gtk.events_pending():
gtk.main_iteration()

==== Adding Pygame to a PyGTK activity ====

To add Pygame to an existing Sugar activity, create a PygameCanvas widget and call
run_pygame on it.

widget = sugargame.canvas.PygameCanvas(self)
vbox.pack_start(widget)

widget.run_pygame(self.game.run)

Due to limitations of Pygame and SDL, there can only be one PygameCanvas in the
entire activity.

The argument to run_pygame is a function structured like a Pygame program. In the
main loop, remember to dispatch GTK messages using gtk.main_iteration().

def main_loop():
clock = pygame.time.Clock()
screen = pygame.display.get_surface()

while self.running:
# Pump GTK messages.
while gtk.events_pending():
gtk.main_iteration()

# Pump PyGame messages.
for event in pygame.event.get():
if event.type == pygame.QUIT:
return
elif event.type == pygame.VIDEORESIZE:
pygame.display.set_mode(event.size, pygame.RESIZABLE)

# Check the mouse position
x, y = pygame.mouse.get_pos()

# Clear Display
screen.fill((255,255,255)) #255 for white

# Draw stuff here
.................

# Flip Display
pygame.display.flip()

# Try to stay at 30 FPS
self.clock.tick(30)

== Support ==

For help with Sugargame, please email the Sugar Labs development list:

: sugar-devel@lists.sugarlabs.org

Sugargame is developed by Wade Brainerd <wadetb@gmail.com>.

It is loosely based on the source code to the olpcgames framework, developed by
the One Laptop Per Child project.

=== Changelog ===

====v1.1====
* Fix bugs in event handling. (Pablo Moleri)
* Remove reference to gtk.Socket.get_window() method, which is missing in older versions of PyGTK.

====v1.0====
* Initial version of Sugargame

Development Team/Sugargame

2010-06-27T17:32:48Z

Wade: /* Changelog */

== Sugargame ==

Sugargame is a Python package which allows [http://www.pygame.org/ Pygame]
programs to run well under Sugar.
It is fork of the olcpgames framework, which is no longer maintained.

http://git.sugarlabs.org/projects/sugargame

What it does:

* Wraps a Sugar activity around an existing Pygame program with few changes
* Allows Sugar toolbars and other widgets to be added to the activity UI
* Provides hooks for saving to and restoring from the Journal

==== Differences between Sugargame and olpcgames ====

The olpcgames framework provides a wrapper around Pygame which attempts to
allow a Pygame program to run mostly unmodified under Sugar. To this end,
the Pygame program is run in a separate thread with its own Pygame message
loop while the main thread runs the GTK message loop. Also, olpcgames wraps
Sugar APIs such as the journal and mesh into a Pygame-like API.

Sugargame takes a simpler approach; it provides a way to embed Pygame into a
GTK widget. The Sugar APIs are used to interact with Sugar, the Pygame APIs
are used for the game.

Sugargame advantages:

* Simpler code
* More elegant interface between Pygame and GTK
* Runs as a single thread: no thread related segfaults
* Possible to use Sugar widgets with Pygame

Sugargame limitations:

* No support for Pango or SVG sprites (yet)

== Using Sugargame ==

See also [[Development Team/Sugargame/Examples]].

==== Wrapping a Pygame program ====

To use Sugargame to Sugarize a Pygame program, set up an activity directory and
copy the Sugargame package to it.

The activity directory should look something like this:

activity/ - Activity directory: activity.info, SVG icon, etc.
sugargame/ - Sugargame package
MyActivity.py - Activity class
mygame.py - Pygame code
setup.py - Install script

To make the Activity class, start with test/TestActivity.py from the Sugargame
distribution.

The activity should create a single PygameCanvas widget and call run_pygame on it.
Pass the main loop function of the Pygame program.

self._canvas = sugargame.canvas.PygameCanvas(self)
self.set_canvas(self._canvas)

# Start the game running.
self._canvas.run_pygame(self.game.run)

In your Pygame main loop, pump the GTK message loop:

while gtk.events_pending():
gtk.main_iteration()

==== Adding Pygame to a PyGTK activity ====

To add Pygame to an existing Sugar activity, create a PygameCanvas widget and call
run_pygame on it.

widget = sugargame.canvas.PygameCanvas(self)
vbox.pack_start(widget)

widget.run_pygame(self.game.run)

Due to limitations of Pygame and SDL, there can only be one PygameCanvas in the
entire activity.

The argument to run_pygame is a function structured like a Pygame program. In the
main loop, remember to dispatch GTK messages using gtk.main_iteration().

def main_loop():
clock = pygame.time.Clock()
screen = pygame.display.get_surface()

while self.running:
# Pump GTK messages.
while gtk.events_pending():
gtk.main_iteration()

# Pump PyGame messages.
for event in pygame.event.get():
if event.type == pygame.QUIT:
return
elif event.type == pygame.VIDEORESIZE:
pygame.display.set_mode(event.size, pygame.RESIZABLE)

# Clear Display
screen.fill((255,255,255)) #255 for white

# Draw stuff here
.................

# Flip Display
pygame.display.flip()

# Try to stay at 30 FPS
self.clock.tick(30)

== Support ==

For help with Sugargame, please email the Sugar Labs development list:

: sugar-devel@lists.sugarlabs.org

Sugargame is developed by Wade Brainerd <wadetb@gmail.com>.

It is loosely based on the source code to the olpcgames framework, developed by
the One Laptop Per Child project.

=== Changelog ===

====v1.1====
* Fix bugs in event handling. (Pablo Moleri)
* Remove reference to gtk.Socket.get_window() method, which is missing in older versions of PyGTK.

====v1.0====
* Initial version of Sugargame

Blocku

2010-02-01T17:17:19Z

Wade: moved Blocku to Activities/Blocku: Preserve wiki structure

#REDIRECT [[Activities/Blocku]]

Activities/Blocku

2010-02-01T17:17:19Z

Wade: moved Blocku to Activities/Blocku: Preserve wiki structure

[[Image:blocku.png]]

Blocku is a puzzle game consisting of filling a grid with squares by matching the squares sides by following a constraint. Blocku is a game that can be used by teachers to teach a multitude of subjects to students. The teacher will be able to create a constraint such as match the formula to the answer or A + B = C. Then the teacher makes a list with two columns. Each row in the columns is a pair of of matching objects. The first row of column A matches the first row of column B. Using this formula the game will randomly assign the objects of each column to square blocks, one object per side. The student then has to put all the pieces in a grid so that pairs on the sides of the squares follow the constraint. The student will be able to move the pieces as well as rotate them.

==Description (original)==
Blocku is a math based jigsaw puzzle. Blocku will come with a few pre-made puzzles. It will have a teacher edit tool where teachers can make their own puzzles. Puzzles can be as complicated as a castle or as simple as a square. The teacher will be given a grid where he/she can specify how the puzzle is supposed to look. Then the teacher chooses what type of operator he/she wants (+, -, x, /). Then the teacher inputs the answer. The activity randomly chooses what number will appear on the sides of each square.

To complete each puzzle the student has to match the sides of squares together so that the numbers finish the math equation at the top of the screen. The puzzle is completed when all pieces are used and are in the correct positions. Below is an example of how a game may progress.

==Student==
The student will be able to choose from past made puzzles as practice or from pre-existing puzzles for fun as a way to play Blocku. When the teacher is in control they will be able to join the class with the task at hand.
*Can choose to use pre-made puzzles
*Can choose difficulty
*Can choose grid size
*Can choose the set of numbers
*Can choose operators used
*Is given the answer then the puzzle

==Teacher==
The teacher here would set all of these preferences and then share the activity, then they can look at statistics based on the class. The main basis here would be time but also an error rate should be tracked along with this data.
*Can set difficulty
*Can set grid size
*Can set the set of numbers
*Can set the operators used

==Updates==
01.14.2010 Updated the Wiki Page with New Links

01.16.2010 Updated the Wiki Page with new suggestions

01.21.2010 Updated the Wiki Page with new description, milestones, and logo

01.27.2010 Added in Fran, Added in summaries for student/teachers

==Contacts==
[[user:mdemayo|Mark DeMayo]]

[[user:Coolestdude1|Ariel Zamparini]]

[[user:iogburu|Ihudiya Ogburu]]

[[user:Fran Rogers|Fran Rogers]]

==Development Meetings==

4pm-6pm Wednesday January 20, 2010

4pm Thursday January 28, 2010 (IRC)

==Sketch Up==
[[Image:example3.jpg]].

[[Image:example1.jpg]].

[[Image:example2.jpg]].

==Milestones==
-<s>Decide which program to use as a foundation. (Tetravex, Super Cube, Jigsaw-Puzzle)</s>

-Display a graphical interface.

-Display squares with numbers.

-Make squares movable and able to be rotated.

==Bugs/Fixes==
==Game Suggestions==

*Benjamin M. Schwartz (via email)

I think it's great. Three points:
1) Users probably don't want to play many games of the same operation
(e.g. x+y=10), and the teacher probably doesn't want to create a new game
for every operation. You should allow users to select a range of
operations (e.g. numbers up to 12, + - and *) and have the game select a
random operation from the set for each game.
2) There are some interesting possibilities for using network collab
between users and teachers, but work on that last. To start, users should
just punch in the operation (or range of operations) when the activity
launches. Teachers can just tell the students what settings to use, and
then look at the screens to verify.
3) The visual structure of the game seems almost identical to Gnome's
Tetravex. In the spirit of Open Source, you should consider reusing the
Tetravex gameboard display code.
--Ben

*Wade Brainerd (via email)

Looks great Mark! Feel free to get in touch with me if you need any
help with implementation.
I agree with Greg that this would be a good target for PyGame.
Regarding the game design, you should consider adding some sense of
progress, or else players will get tired quickly. Some ideas:
- Start with two cards, gradually ramp up to 9.
- There needs to be a good "snapping" mechanism when dropping, so
users don't get frustrated by trying to line the cards up.
- Adding the ability to rotate the cards in 90 degree increments would
add to the challenge.
- Your notion of customization seems limited to replacing the square
with a graphic, which might obscure the number. Is this really a good
way to customize it?
- I agree with Ben that when you start the game you should first
select which types of puzzles (* + - / etc) you want, how many
squares, whether rotation is allowed. No need for the teacher to be
involved.
- Why limit it to numbers? E.g. how about comparisons like "X is
heaver than Y" and on the sides of the cards are things like
"elephant", "bacteria", etc. Or "X is newer than Y", etc. This is
where customization would be cool. Let the teacher define a
relationship, and input a series of terms, and define which pairs meet
that relationship. This would be called a "set", and could be
exported to the Journal.
Good luck with your project!

*David Farning (via email)

Very clever. I just cut made a cut out of the game out of paper. My
1st grade niece played with it for over half an hour. It will be a
hit on her XO.
david

*Greg DeKoenigsberg (via email)

Mark, this looks like a brilliant little activity. Simple, fun gameplay, extensible. Really great.
Some thoughts:
1. I'd love to see this as primarily a PyGame activity, with just enough "Sugar" to run it on Sugar
easily, but also easily available as a Windows or Mac activity. If done well, this is precisely
the sort of activity that could cross over. (Which is, in fact, how I'd like to see most Sugar
games built.)
2. Always think a little bit (but not too much) about assessment. The student knows they're
getting better because they are "leveling up". The teacher knows the kid is getting better
because... how? Game data is pushed up to a server... somehow? Dunno if anyone is paying
attention to this question, but it would be great if there were a simple way to allow
teachers to
aggregate "high score" data, which really doubles as assessment data in cases like this.
A great start. I look forward to seeing what it becomes.
--g

==Public Git Repository==
http://git.sugarlabs.org/projects/blocku

==Public IRC Channel==
Server: irc.freenode.net

Channel: #blocku

==Comments==

Deployments

2010-01-25T14:36:04Z

Wade:

<noinclude>{{GoogleTrans-en}}</noinclude>

Deployments are schools where students are using Sugar to learn.

See [[Deployment Team/Places]] and [[olpc:Deployments]] for a partial accounting.

==Policy==
* [[Deployments/Policy]] How and why to document a deployment.

==Subpages==
{{Special:PrefixIndex/{{PAGENAMEE}}/}}

[[Category:Deployment]]

Deployments

2010-01-17T23:10:00Z

Wade:

<noinclude>{{GoogleTrans-en}}</noinclude>

Deployments are schools where students are using Sugar to learn.

==Policy==
* [[Deployments/Policy]] How and why to document a deployment.

==Subpages==
{{Special:PrefixIndex/{{PAGENAMEE}}/}}

[[Category:Deployment]]

Deployments/Deployment Template

2010-01-17T23:07:20Z

Wade: /* Hardware */

<noinclude>{{TOCright}}
[[Category:Deployment Page Incomplete]]
[[Category:Deployment|<Deployment Name>]]

</noinclude>

'''Comments and Explanations:'''

There are comments (in italic) providing guidance to fill out each section, see also the [[Deployments/Policy|Deployment Policy Page]] for a more detailed explanation of the deployment documentation process. '''Copy the source to a ''new page'' named Deployments/''Your Deployment Name'' before making changes! DO NOT EDIT THIS TEMPLATE.'''





== Summary ==
''A sentence or two summarizing this Sugar deployment. This information is used for the deployment summary page.''

== Contact ==
''This should link to one or more people who are willing to act as ambassadors between Sugar Labs and this deployment.''
* Name: [[User:AcountName| Your Name]]

''Include your email address that you can be reached should people want to make contact with this deployment''
* Email: <your email address so we can contact you, invite you to meetings, etc.>

== Location ==
''Describe the location of the deployment''

== Language ==
''What language does the deployment use? Include the language code, e.g. en_US, if possible.''

== Size ==
''Describe the number of students, teachers, and IT staff using Sugar.''

== Hardware ==
''Describe the number and type of computers Sugar is running on, e.g. 150 OLPC XO-1 Laptops. Also describe any servers are used and what software they run. Additional equipment, like solar power generators, can also be included.''

== Technical Details ==
''This should list which version of Sugar is being used, e.g. 0.82 or SoaS Blueberry.''
* Sugar version: <SUGAR VERSION>

''Describe the base operating system being used, e.g. Fedora 12.''
* OS distribution: <OS DISTRO>

== Activity Usage ==
''Describe which Sugar activities are used in the classroom.''
* <ACTIVITY 1>
* <ACTIVITY 2>

== Curriculum ==
''Provide any notes about how Sugar is being used in the classroom.''

== History ==
''Describe how and when the deployment got started, its growth and changes, etc.''

== Links ==
''Provide links to deployment websites, additional wiki pages, studies, papers, etc.''

== Comments and Discussion ==
* See [[{{TALKPAGENAME}}|discussion tab for this deployment]]

Deployments/Deployment Template

2010-01-17T23:06:11Z

Wade: /* Equipment */

<noinclude>{{TOCright}}
[[Category:Deployment Page Incomplete]]
[[Category:Deployment|<Deployment Name>]]

</noinclude>

'''Comments and Explanations:'''

There are comments (in italic) providing guidance to fill out each section, see also the [[Deployments/Policy|Deployment Policy Page]] for a more detailed explanation of the deployment documentation process. '''Copy the source to a ''new page'' named Deployments/''Your Deployment Name'' before making changes! DO NOT EDIT THIS TEMPLATE.'''





== Summary ==
''A sentence or two summarizing this Sugar deployment. This information is used for the deployment summary page.''

== Contact ==
''This should link to one or more people who are willing to act as ambassadors between Sugar Labs and this deployment.''
* Name: [[User:AcountName| Your Name]]

''Include your email address that you can be reached should people want to make contact with this deployment''
* Email: <your email address so we can contact you, invite you to meetings, etc.>

== Location ==
''Describe the location of the deployment''

== Language ==
''What language does the deployment use? Include the language code, e.g. en_US, if possible.''

== Size ==
''Describe the number of students, teachers, and IT staff using Sugar.''

== Hardware ==
''Describe the number and type of computers Sugar is running on, e.g. 150 OLPC XO-1 Laptops.''

== Technical Details ==
''This should list which version of Sugar is being used, e.g. 0.82 or SoaS Blueberry.''
* Sugar version: <SUGAR VERSION>

''Describe the base operating system being used, e.g. Fedora 12.''
* OS distribution: <OS DISTRO>

== Activity Usage ==
''Describe which Sugar activities are used in the classroom.''
* <ACTIVITY 1>
* <ACTIVITY 2>

== Curriculum ==
''Provide any notes about how Sugar is being used in the classroom.''

== History ==
''Describe how and when the deployment got started, its growth and changes, etc.''

== Links ==
''Provide links to deployment websites, additional wiki pages, studies, papers, etc.''

== Comments and Discussion ==
* See [[{{TALKPAGENAME}}|discussion tab for this deployment]]

Deployments/Deployment Template

2010-01-17T23:05:55Z

Wade:

<noinclude>{{TOCright}}
[[Category:Deployment Page Incomplete]]
[[Category:Deployment|<Deployment Name>]]

</noinclude>

'''Comments and Explanations:'''

There are comments (in italic) providing guidance to fill out each section, see also the [[Deployments/Policy|Deployment Policy Page]] for a more detailed explanation of the deployment documentation process. '''Copy the source to a ''new page'' named Deployments/''Your Deployment Name'' before making changes! DO NOT EDIT THIS TEMPLATE.'''





== Summary ==
''A sentence or two summarizing this Sugar deployment. This information is used for the deployment summary page.''

== Contact ==
''This should link to one or more people who are willing to act as ambassadors between Sugar Labs and this deployment.''
* Name: [[User:AcountName| Your Name]]

''Include your email address that you can be reached should people want to make contact with this deployment''
* Email: <your email address so we can contact you, invite you to meetings, etc.>

== Location ==
''Describe the location of the deployment''

== Language ==
''What language does the deployment use? Include the language code, e.g. en_US, if possible.''

== Size ==
''Describe the number of students, teachers, and IT staff using Sugar.''

== Equipment ==
''Describe the number and type of computers Sugar is running on, e.g. 150 OLPC XO-1 Laptops.''

== Technical Details ==
''This should list which version of Sugar is being used, e.g. 0.82 or SoaS Blueberry.''
* Sugar version: <SUGAR VERSION>

''Describe the base operating system being used, e.g. Fedora 12.''
* OS distribution: <OS DISTRO>

== Activity Usage ==
''Describe which Sugar activities are used in the classroom.''
* <ACTIVITY 1>
* <ACTIVITY 2>

== Curriculum ==
''Provide any notes about how Sugar is being used in the classroom.''

== History ==
''Describe how and when the deployment got started, its growth and changes, etc.''

== Links ==
''Provide links to deployment websites, additional wiki pages, studies, papers, etc.''

== Comments and Discussion ==
* See [[{{TALKPAGENAME}}|discussion tab for this deployment]]

Deployments/Deployment Template

2010-01-17T23:04:14Z

Wade:

<noinclude>{{TOCright}}
[[Category:Deployment Page Incomplete]]
[[Category:Deployment|<Deployment Name>]]

</noinclude>

'''Comments and Explanations:'''

There are comments (in italic) providing guidance to fill out each section, see also the [[Deployments/Policy|Deployment Policy Page]] for a more detailed explanation of the deployment documentation process. '''Copy the source to a ''new page'' named Deployments/''Your Deployment Name'' before making changes! DO NOT EDIT THIS TEMPLATE.'''





== Summary ==
''A sentence or two summarizing this Sugar deployment. This information is used for the deployment summary page.''

== Contact ==
''This should link to one or more people who are willing to act as ambassadors between Sugar Labs and this deployment.''
* Name: [[User:AcountName| Your Name]]

''Include your email address that you can be reached should people want to make contact with this deployment''
* Email: <your email address so we can contact you, invite you to meetings, etc.>

== Location ==
''Describe the location of the deployment''

== Language ==
''What language does the deployment use? Include the language code, e.g. en_US, if possible.''

== Size ==
''Describe the number of students, teachers, and IT staff using Sugar.''

== Equipment ==
''Describe the number and type of computers Sugar is running on, e.g. 150 OLPC XO-1 Laptops.''

== Technical Details ==
''This should list which version of Sugar is being used, e.g. 0.82 or SoaS Blueberry.''
Sugar version: <SUGAR VERSION>
''Describe the base operating system being used, e.g. Fedora 12.''
OS distribution: <OS DISTRO>

== Activity Usage ==
''Describe which Sugar activities are used in the classroom.''
* <ACTIVITY 1>
* <ACTIVITY 2>

== Curriculum ==
''Provide any notes about how Sugar is being used in the classroom.''

== History ==
''Describe how and when the deployment got started, its growth and changes, etc.''

== Links ==
''Provide links to deployment websites, additional wiki pages, studies, papers, etc.''

== Comments and Discussion ==
* See [[{{TALKPAGENAME}}|discussion tab for this deployment]]

Deployments

2010-01-17T23:03:22Z

Wade:

<noinclude>{{GoogleTrans-en}}</noinclude>

Deployments are schools where students are learning using Sugar.

==Policy==
* [[Deployments/Policy]] How and why to document a deployment.

==Subpages==
{{Special:PrefixIndex/{{PAGENAMEE}}/}}

[[Category:Deployment]]

Deployments

2010-01-17T23:01:38Z

Wade:

<noinclude>{{GoogleTrans-en}}</noinclude>

==Policy==
* [[Deployments/Policy]] How and why to document a deployment.

==Subpages==
{{Special:PrefixIndex/{{PAGENAMEE}}/}}

[[Category:Deployment]]

Deployments/Policy

2010-01-17T23:01:08Z

Wade: Created page with '== Why should I document my deployment? == The main goal of listing deployments on the SugarLabs wiki is to increase communication between the development community and the users…'

== Why should I document my deployment? ==
The main goal of listing deployments on the SugarLabs wiki is to increase communication between the development community and the users. Ultimately, this communication will serve to enhance the Sugar learning platform.

By providing a basic description of each deployment and its needs, Sugar developers are motivated to working on making Sugar a great learning experience.

== How to document a deployment ==
To document a deployment, copy the [[Deployments/Deployment Template|deployment template page]] into a new Wiki page named Deployments/Your Deployment Name.

Edit the new page, replacing the template comments in italics with the appropriate details.

From time to time, please update the page with new information.

Deployments/Deployment Template

2010-01-17T22:27:02Z

Wade: Created page with '<noinclude>{{TOCright}} Category:Deployment Page Incomplete <Deployment Name> <!-- You can add categories to tie features back to real deployments/sch…'

<noinclude>{{TOCright}}
[[Category:Deployment Page Incomplete]]
[[Category:Deployment|<Deployment Name>]]

</noinclude>

'''Comments and Explanations:'''

There are comments (in italic) providing guidance to fill out each section, see also the [[Deployments/Policy|Deployment Policy Page]] for a more detailed explanation of the deployment documentation process. '''Copy the source to a ''new page'' named Deployments/''Your Deployment Name'' before making changes! DO NOT EDIT THIS TEMPLATE.'''





== Summary ==
''A sentence or two summarizing this Sugar deployment. This information is used for the deployment summary page.''

== Contact ==
''This should link to one or more people who are willing to act as ambassadors between Sugar Labs and this deployment.''
* Name: [[User:AcountName| Your Name]]

''Include your email address that you can be reached should people want to make contact with this deployment''
* Email: <your email address so we can contact you, invite you to meetings, etc.>

== Location ==
''Describe the location of the deployment''

== Language ==
''What language does the deployment use? Include the language code, e.g. en_US, if possible.''

== Size ==
''Describe the number of students, teachers, and IT staff using Sugar.''

== Equipment ==
''Describe the number and type of computers Sugar is running on, e.g. 150 OLPC XO-1 Laptops.''

== Technical Details ==
''This should list which version of Sugar is being used, e.g. 0.82 or SoaS Blueberry.''
Sugar version: <SUGAR VERSION>
''Describe the base operating system being used, e.g. Fedora 12.''
OS distribution: <OS DISTRO>

== Activity Usage ==
''Describe which Sugar activities are used in the classroom.''
* <ACTIVITY 1>
* <ACTIVITY 2>

== Curriculum ==
''Provide any notes about how Sugar is being used in the classroom.''

== Links ==
''Provide links to deployment websites, additional wiki pages, studies, papers, etc.''

== Comments and Discussion ==
* See [[{{TALKPAGENAME}}|discussion tab for this deployment]]

Deployments

2010-01-17T22:09:55Z

Wade: Created page with '<noinclude>{{GoogleTrans-en}}</noinclude> ==Policy== * Deployments/Policy How to document a deployment. ==Subpages== {{Special:PrefixIndex/{{PAGENAMEE}}/}} [[Category:Depl…'

<noinclude>{{GoogleTrans-en}}</noinclude>

==Policy==
* [[Deployments/Policy]] How to document a deployment.

==Subpages==
{{Special:PrefixIndex/{{PAGENAMEE}}/}}

[[Category:Deployment]]

Features/Problem Reports

2009-12-20T14:23:33Z

Wade: /* Detailed Description */

<noinclude>{{GoogleTrans-en}}{{TOCright}}
[[Category:Feature Page Incomplete]]
[[Category:Feature|Problem Reports]]</noinclude>

== Summary ==
The "Report a problem" control panel provides a way for the user to report issues with the Sugar shell and activities. The control panel uploads system information and logs, along with the user's description of the problem.

== Owner ==
* Name: [[User:Wade|Wade Brainerd]]
* Email: wadetb@gmail.com

== Current status ==
* Targeted release: 0.88
* Last updated: October 16th, 2009
* Percentage of completion: 90%

== Detailed Description ==
A new control panel will be added, titled "Report a problem". This panel contains a description box and an Upload report button. When the button is pressed, the description and system logs are uploaded to a central Sugar Labs server.

The central server logs the problem reports in a database and stores a copy of the logs. It also analyzes the logs for specific errors (such as Python Tracebacks). When a problem report is added, the server sends an email out to a mailing list of developers and interested parties.

When a problem is detected in an Activity, such as failure to launch, Sugar will offer a "Report problem" button which takes the user directly to the control panel.

After uploading, the user is given a Report ID number (a small decimal number). They can use this if they wish to follow up with the Sugar developers by email.

==== For Deployments ====
Deployments can set up their own log collection server, if desired. All that is required is a web server with PHP and sqlite.

The URL of the log server is configured using a GConf key and can be customized per deployment.

It's important to understand that this system is intended to be as automated as possible, so deployments should not expect to have a staff of support personnel monitoring problem reports, but can instead use them to get a general sense of what problems are most common.

[[File:Problem-report.jpg]]

== Benefit to Sugar ==
Currently there is no mechanism for non-technical users to submit problem reports. In order to inform the Sugar or Activity developers of a problem, a user has two options:

* Create a Trac account and enter a bug.
* Write an email to sugar-devel@lists.sugarlabs.org.

The first option is time consuming and requires the user to fill in confusing fields such as Component and Version manually. The second option requires the user to have an email account, and the report is not logged anywhere. Neither option is convenient or provides relevant details about the problem.

The new control panel offers a way for casual users to report problems encountered in Sugar. It also supplies a high level of detail about the problem to the developers.

The reason problem reports are not added directly to Trac is that we don't want to spam the database with spurious reports. Problem reports are intended to be triaged by subscribers to the mailing list, and then either bugged or noted on an existing ticket.

== Scope ==
A prototype of the control panel and server have been finished and posted to [http://trac.sugarlabs.org/ticket/1439 #1439] as patches.

The collection server is currently running at logcollect.sugarlabs.org. Logs are emailed out to the sugar-reports@lists.sugarlabs.org mailing list.

Work left to do:
* <strike>The control panel needs a SVG icon.</strike> [[File:Toolbar-bug.png]]
* When an activity exits, if its log contains an exception report, Sugar should offer to report the problem. When an activity fails to launch, Sugar should display an error on the launch window and offer to report the problem instead of timing out.
* <strike>The server needs to be installed on the SugarLabs infrastructure and the reports mailing list needs to be created (sugar-reports@lists.sugarlabs.org?).</strike> The server is now live at logcollect.sugarlabs.org. The mailing list sugar-reports@lists.sugarlabs.org now exists.
* <strike>For deployments, there should be a way to override the server URL.</strike> The server URL now comes from Gconf.
* <strike>The Log activity needs to have its Upload Logs button replaced by a button that opens the control panel.</strike> Most likely we will remove the button from Log, but patches for both options have been posted to the ticket.

== How To Test ==
{{:{{PAGENAME}}/Testing}}

== User Experience ==
The user will notice a new control panel. When an activity fails to launch or otherwise suffers an exception, the user will be offered an opportunity to report the problem.

== Dependencies ==
None

== Contingency Plan ==
Nothing depends on this feature. If it's not ready in time it can simply be omitted.

== Documentation ==
Ideally this feature would be documented as part of the FLOSS manual.

Also, instructions for deploying the log server and configuring the URL via gconf should be documented on the Wiki.

== Release Notes ==
A mention of how to customize the server URL would be useful.

== Comments and Discussion ==
* See [[{{TALKPAGENAME}}|discussion tab for this feature]]

----
''You can add categories to tie features back to real deployments/schools requesting them, for example <nowiki>[[</nowiki>Category:Features requested by School Xyz]]''

Features/Problem Reports

2009-12-20T14:22:05Z

Wade: /* Detailed Description */

<noinclude>{{GoogleTrans-en}}{{TOCright}}
[[Category:Feature Page Incomplete]]
[[Category:Feature|Problem Reports]]</noinclude>

== Summary ==
The "Report a problem" control panel provides a way for the user to report issues with the Sugar shell and activities. The control panel uploads system information and logs, along with the user's description of the problem.

== Owner ==
* Name: [[User:Wade|Wade Brainerd]]
* Email: wadetb@gmail.com

== Current status ==
* Targeted release: 0.88
* Last updated: October 16th, 2009
* Percentage of completion: 90%

== Detailed Description ==
A new control panel will be added, titled "Report a problem". This panel contains a description box and an Upload report button. When the button is pressed, the description and system logs are uploaded to a central Sugar Labs server.

The central server logs the problem reports in a database and stores a copy of the logs. It also analyzes the logs for specific errors (such as Python Tracebacks). When a problem report is added, the server sends an email out to a mailing list of developers and interested parties.

When a problem is detected in an Activity, such as failure to launch, Sugar will offer a "Report problem" button which takes the user directly to the control panel.

After uploading, the user is given a Report ID number (a small decimal number). They can use this if they wish to follow up with the Sugar developers by email.

[[File:Problem-report.jpg]]

==== For Deployments ====
Deployments can set up their own log collection server, if desired. All that is required is a web server with PHP and sqlite.

The URL of the log server is configured using a GConf key and can be customized per deployment.

== Benefit to Sugar ==
Currently there is no mechanism for non-technical users to submit problem reports. In order to inform the Sugar or Activity developers of a problem, a user has two options:

* Create a Trac account and enter a bug.
* Write an email to sugar-devel@lists.sugarlabs.org.

The first option is time consuming and requires the user to fill in confusing fields such as Component and Version manually. The second option requires the user to have an email account, and the report is not logged anywhere. Neither option is convenient or provides relevant details about the problem.

The new control panel offers a way for casual users to report problems encountered in Sugar. It also supplies a high level of detail about the problem to the developers.

The reason problem reports are not added directly to Trac is that we don't want to spam the database with spurious reports. Problem reports are intended to be triaged by subscribers to the mailing list, and then either bugged or noted on an existing ticket.

== Scope ==
A prototype of the control panel and server have been finished and posted to [http://trac.sugarlabs.org/ticket/1439 #1439] as patches.

The collection server is currently running at logcollect.sugarlabs.org. Logs are emailed out to the sugar-reports@lists.sugarlabs.org mailing list.

Work left to do:
* <strike>The control panel needs a SVG icon.</strike> [[File:Toolbar-bug.png]]
* When an activity exits, if its log contains an exception report, Sugar should offer to report the problem. When an activity fails to launch, Sugar should display an error on the launch window and offer to report the problem instead of timing out.
* <strike>The server needs to be installed on the SugarLabs infrastructure and the reports mailing list needs to be created (sugar-reports@lists.sugarlabs.org?).</strike> The server is now live at logcollect.sugarlabs.org. The mailing list sugar-reports@lists.sugarlabs.org now exists.
* <strike>For deployments, there should be a way to override the server URL.</strike> The server URL now comes from Gconf.
* <strike>The Log activity needs to have its Upload Logs button replaced by a button that opens the control panel.</strike> Most likely we will remove the button from Log, but patches for both options have been posted to the ticket.

== How To Test ==
{{:{{PAGENAME}}/Testing}}

== User Experience ==
The user will notice a new control panel. When an activity fails to launch or otherwise suffers an exception, the user will be offered an opportunity to report the problem.

== Dependencies ==
None

== Contingency Plan ==
Nothing depends on this feature. If it's not ready in time it can simply be omitted.

== Documentation ==
Ideally this feature would be documented as part of the FLOSS manual.

Also, instructions for deploying the log server and configuring the URL via gconf should be documented on the Wiki.

== Release Notes ==
A mention of how to customize the server URL would be useful.

== Comments and Discussion ==
* See [[{{TALKPAGENAME}}|discussion tab for this feature]]

----
''You can add categories to tie features back to real deployments/schools requesting them, for example <nowiki>[[</nowiki>Category:Features requested by School Xyz]]''

Features/Problem Reports

2009-12-20T14:20:52Z

Wade: /* Documentation */

<noinclude>{{GoogleTrans-en}}{{TOCright}}
[[Category:Feature Page Incomplete]]
[[Category:Feature|Problem Reports]]</noinclude>

== Summary ==
The "Report a problem" control panel provides a way for the user to report issues with the Sugar shell and activities. The control panel uploads system information and logs, along with the user's description of the problem.

== Owner ==
* Name: [[User:Wade|Wade Brainerd]]
* Email: wadetb@gmail.com

== Current status ==
* Targeted release: 0.88
* Last updated: October 16th, 2009
* Percentage of completion: 90%

== Detailed Description ==
A new control panel will be added, titled "Report a problem". This panel contains a description box and an Upload report button. When the button is pressed, the description and system logs are uploaded to a central Sugar Labs server.

The central server logs the problem reports in a database and stores a copy of the logs. It also analyzes the logs for specific errors (such as Python Tracebacks). When a problem report is added, the server sends an email out to a mailing list of developers and interested parties.

When a problem is detected in an Activity, such as failure to launch, Sugar will offer a "Report problem" button which takes the user directly to the control panel.

After uploading, the user is given a Report ID number (a small decimal number). They can use this if they wish to follow up with the Sugar developers by email.

[[File:Problem-report.jpg]]

== Benefit to Sugar ==
Currently there is no mechanism for non-technical users to submit problem reports. In order to inform the Sugar or Activity developers of a problem, a user has two options:

* Create a Trac account and enter a bug.
* Write an email to sugar-devel@lists.sugarlabs.org.

The first option is time consuming and requires the user to fill in confusing fields such as Component and Version manually. The second option requires the user to have an email account, and the report is not logged anywhere. Neither option is convenient or provides relevant details about the problem.

The new control panel offers a way for casual users to report problems encountered in Sugar. It also supplies a high level of detail about the problem to the developers.

The reason problem reports are not added directly to Trac is that we don't want to spam the database with spurious reports. Problem reports are intended to be triaged by subscribers to the mailing list, and then either bugged or noted on an existing ticket.

== Scope ==
A prototype of the control panel and server have been finished and posted to [http://trac.sugarlabs.org/ticket/1439 #1439] as patches.

The collection server is currently running at logcollect.sugarlabs.org. Logs are emailed out to the sugar-reports@lists.sugarlabs.org mailing list.

Work left to do:
* <strike>The control panel needs a SVG icon.</strike> [[File:Toolbar-bug.png]]
* When an activity exits, if its log contains an exception report, Sugar should offer to report the problem. When an activity fails to launch, Sugar should display an error on the launch window and offer to report the problem instead of timing out.
* <strike>The server needs to be installed on the SugarLabs infrastructure and the reports mailing list needs to be created (sugar-reports@lists.sugarlabs.org?).</strike> The server is now live at logcollect.sugarlabs.org. The mailing list sugar-reports@lists.sugarlabs.org now exists.
* <strike>For deployments, there should be a way to override the server URL.</strike> The server URL now comes from Gconf.
* <strike>The Log activity needs to have its Upload Logs button replaced by a button that opens the control panel.</strike> Most likely we will remove the button from Log, but patches for both options have been posted to the ticket.

== How To Test ==
{{:{{PAGENAME}}/Testing}}

== User Experience ==
The user will notice a new control panel. When an activity fails to launch or otherwise suffers an exception, the user will be offered an opportunity to report the problem.

== Dependencies ==
None

== Contingency Plan ==
Nothing depends on this feature. If it's not ready in time it can simply be omitted.

== Documentation ==
Ideally this feature would be documented as part of the FLOSS manual.

Also, instructions for deploying the log server and configuring the URL via gconf should be documented on the Wiki.

== Release Notes ==
A mention of how to customize the server URL would be useful.

== Comments and Discussion ==
* See [[{{TALKPAGENAME}}|discussion tab for this feature]]

----
''You can add categories to tie features back to real deployments/schools requesting them, for example <nowiki>[[</nowiki>Category:Features requested by School Xyz]]''

Activities/Colors

2009-12-10T00:09:21Z

Wade: /* Colors! developers' page */

<noinclude>[[Category:Activities|Colors!]]</noinclude>

==Colors! developers' page==

===Overview===

Colors is a simple natural media painting activity for the XO laptop, based on a Nintendo DS program by Jens Andersson.

Rather than constructing images from geometric shapes, the user is encouraged to keep painting on their work until it looks right, starting with rough strokes and then adding extra details.

The activity features soft brushes, collaborative painting, the ability to watch tutorial paintings as they are painted, and a variety of input methods including "video paint" using the webcam.

===Setting up a Wacom tablet===

Colors! versions 11 and above support USB Wacom tablets, such as the [http://www.amazon.com/Bamboo-Small-Pen-Tablet-Only/dp/B000V9T2JA/ref=sr_1_22?ie=UTF8&s=electronics&qid=1228608694&sr=1-22 Wacom Bamboo] ($60 at Amazon).

====On OLPC XO-1====

Wacom support requires OLPC Software Release 8.2.0, so update if you are on an older build.

To use your USB Wacom tablet with Colors, you need to do a little work at the Terminal.

wget http://dev.laptop.org/~wadeb/setupwacom.sh
sudo sh setupwacom.sh

This will install the linuxwacom package, download and install the Wacom kernel module, and download and replace your Xorg configuration file with one that supports Wacom tablets.

Restart your XO and launch Colors!. Voila, Wacom support! Check the Sensitive buttons in the Brush Control screen to enable pressure sensitivity for brush size and opacity.

===Resources===

* [http://git.sugarlabs.org/projects/colors Sources]
* [http://activities.sugarlabs.org/en-US/sugar/addon/4050 Downloads and user-land pages]
* [http://wiki.laptop.org/go/Colors%21 Colors! on OLPC wiki]
* Trac Tickets: [http://trac.sugarlabs.org/query?status=accepted&status=assigned&status=closed&status=new&status=reopened&groupdesc=1&group=milestone&component=Colors&order=priority&col=id&col=summary&col=status&col=owner&col=type&col=priority&col=version&col=severity&col=resolution&col=status_field&col=reporter&col=time&col=changetime Sugar Labs] [http://dev.laptop.org/query?status=assigned&status=closed&status=new&status=reopened&groupdesc=1&group=milestone&max=150&component=colors-activity&order=id&col=id&col=summary&col=status&col=owner&col=type&col=next_action&col=changetime OLPC]

Activity Team/Resources

2009-12-09T20:38:06Z

Wade: /* Setting up a Sugar environment */

<noinclude>{{GoogleTrans-en}}{{TeamHeader|Activity Team}}</noinclude>{{TOCright}}

==Getting started in Activity development==
If you have no experience developing Sugar activities, these resources will help get you started.

====Setting up a Sugar environment====
If you use Linux, your best bet is to install [[Development Team/Jhbuild|sugar-jhbuild]]. You will be able to develop in your native environment, treating Sugar as just another desktop application.

If you run MacOS X or Windows, you will need to set up an emulator. For setup instructions and links to pre-configured virtual machines, see [[VirtualBox]].

To develop efficiently using an emulator or a secondary machine (such as an OLPC XO), find an editor which supports editing files over a SFTP connection. [http://www.openkomodo.com/ Komodo Edit] with the Remote Drive Tree extension is a good example.

====Python Reference & Tutorials====
* http://docs.python.org/
* http://diveintopython.org/
* [http://pleac.sourceforge.net/pleac_python/index.html PLEAC - Programming Language Examples Alike Cookbook]

Python is the language Sugar is written in and is also used by most activities. If you don't already know Python well, you should familiarize yourself with it before continuing.

====PyGTK Reference & Tutorials====
* http://www.pygtk.org/docs/pygtk/index.html
* http://www.pygtk.org/docs/pygobject/index.html

PyGTK is the user interface toolkit used by Sugar activities. Bookmark these two links as you will reference them frequently during development.

* http://www.pygtk.org/pygtk2tutorial/index.html

The following sections of the PyGTK tutorial are most relevant to activity development.

* 1. Introduction
* 2. Getting Started
* 3. Moving On
* 4. Packing Widgets
* 5. Widget Overview
* 6. The Button Widget
* 7. Adjustments
* 8. Range Widgets
* 9. Miscellaneous Widgets
* 10. Container Widgets
* 12. Drawing Area

====Sugar Activities====
* [[Development Team/Almanac|Sugar Almanac]]

The Sugar Almanac contains all the information you need to start writing Sugar activities, ranging from directory structure to bundle format to API reference. It also contains answers to common questions and examples of common tasks.

* http://api.sugarlabs.org/

This automatically updated site contains the official API documentation for Sugar. Though it is currently quite sparse, the source code is included with the documentation and it's useful to have that at your fingertips.

====Cairo Graphics====
* http://www.tortall.net/mu/wiki/CairoTutorial

Cairo is the graphics library used in Sugar. The tutorial is a good introduction to the API as well as vector graphics programming in general.

====Pygame====
* http://www.pygame.org/
* [[Development_Team/sugargame]]

Pygame is a library for developing 2D sprite-based games using Python. Sugargame is a package which makes it possible to embed Pygame into a Sugar activity.

====Sugar [[Human Interface Guidelines]] (HIG)====
* [[Human Interface Guidelines]].

Required reading before planning the user interface for your activity. These pages give a good introduction to the thought process behind the Sugar environment and will help a lot when designing your activity.

====i18n (Localisation) Best Practices====
* [[Translation_Team/i18n_Best_Practices]].

Once you have strings in your Activity, here are some general tips which will make your translators happy :-)

====JSON introduction====
* http://www.json.org/fatfree.html

JSON is a data format commonly used to store activity data in the Journal.

* http://simplejson.googlecode.com/svn/tags/simplejson-2.0.8/docs/index.html

Currently, the recommended JSON library is simplejson. It has also become the standard JSON library in Python 2.6+.

NOTE: There is an odd thing about simplejson - in python25 it lives in ''simplejson'' module, but in python26 it uses ''json'' module. So, use something like [http://git.sugarlabs.org/projects/sugar-port/repos/mainline/blobs/master/json.py this] to wrap it.

====Git introduction====
Git is the version control software used by Sugar Labs. It is a distributed version control system and is quite powerful, but requires a lot of command line use.

* [[Activity Team/Git|Git]]

====XML routines====
There are [http://docs.python.org/library/markup.html dozens] Python classes to satisfy the XML standard, but if you want just save/load parameters use "Zen of XML" in Python - [http://effbot.org/zone/element.htm ElementTree] library. It's supported out of the box in Python 2.5 (xml.etree.ElementTree module). In previous versions you'll have to install library by yourself.

But if you just need a simple configuration format to read/write Python objects, check out JSON instead.

====Speech synthesizing====
If you want to add a speech synthesizer for English and other languages, try the [[Development Team/gst-plugins-espeak|gst-plugins-espeak]] plugin for gstreamer.

==Activity Development Resources==
This is an open area for posting links related to activity development.

===Sample code===

* An example of [[Activity Team/Sample code/Ruler|a simple activity that uses Cairo graphics]]
* An [http://uclug.org/images/Sugar.odp OpenOffice presentation] that touches on many of the issues encountered by first-time Sugar developers. Some items covered are: What is Sugar and Sugar Labs; What are some development environments; Some Sugar specific python statements for a PyGTK activity; Activity distribution. You can also [http://media.libsyn.com/media/dsyates/101309uclug0020.ogg listen] to the creator ([http://wiki.sugarlabs.org/go/User:Ossfm ossfm]) give the presentation at a LUG meeting (starting at 9 minutes and 55 seconds).

===References===
* http://docs.python.org/ The official Python documentation.
* http://www.pygtk.org/docs/pygtk/index.html PyGTK API reference
* http://www.pygtk.org/docs/pygobject/index.html PyGObject API reference. Contains a few important things missing from the PyGTK API such as timers and idle callbacks.
* http://api.sugarlabs.org/ The official Sugar API documentation (quite sparse but includes all the source code).
* [[Development Team/Almanac]] Detailed Sugar API overview. Quite in depth and offers answers to common questions.
* http://pygstdocs.berlios.de/ Python GStreamer bindings.
* [[Human Interface Guidelines]] The design behind the Sugar interface. Very important to read and understand before planning your activity's user interface.
* http://cairographics.org/documentation/pycairo/ Cairo Python API reference. Very sparse, use the tutorial instead.
* [[OLPC:Low-level Activity API]] Information on how activities interact with Sugar.
* http://www.pygame.org/ The Pygame game development library.
* [[Development Team/sugargame]] Python package which makes it possible to embed Pygame in a Sugar activity.

===Tutorials and Whitepapers===
* http://diveintopython.org/ An online book which teaches Python step by step.
* http://www.pygtk.org/pygtk2tutorial/index.html A very informative step-by-step introduction to PyGTK.
* http://www.olpcaustria.org/mediawiki/index.php/Activity_handbook Introduction to activity development by OLPC Austria.
* [[OLPC:Sugar Activity Tutorial]] Another introduction to activity development.
* http://www.tortall.net/mu/wiki/CairoTutorial A great introduction to Cairo in PyGTK and vector graphics drawing in general.
* http://www.json.org/fatfree.html An overview of the JSON data format.
* http://simplejson.googlecode.com/svn/tags/simplejson-2.0.8/docs/index.html Documentation for the recommended JSON library.
* [[OLPC:Shared Sugar Activities]] High level overview of collaboration.
* [[OLPC:Collaboration Tutorial]] Step by step tutorial on integrating collaboration into an activity.
* [[Activity_Team/Modifing_an_Activity]] Information describing simple modifications that can be made to common Sugar activities.
* [[Activity Team/Compatibility Tips]] Information on ensuring your activity is portable to the various distributions that run Sugar.

===Community resources===
* http://dev.sugarlabs.org/ Bug tracking for Sugar and activities. Go here to report bugs in the Sugar toolkit. Each activity should have its own component here.
* http://git.sugarlabs.org/ Gitorious source code hosting.
* http://git.sugarlabs.org/events.atom RSS feed of all Sugar development activity. Great for keeping an eye on the project as a whole.

===Non-English resources===
* http://sites.google.com/site/sugaractivities/ Spanish language activity development site in Uruguay.

==Stuck?==

If you have a question, don't hesitate to ask the activity team. We are happy to help and can often save you a lot of hunting for answers.

We hang out in #sugar on irc.freenode.net, and you can always [http://lists.sugarlabs.org/listinfo/sugar-devel subscribe] and post questions to sugar-devel@lists.sugarlabs.org.

[[Category:Activity Team]]
[[Category:Resource]]

Activity Team/Resources

2009-12-09T20:37:32Z

Wade: /* Setting up a Sugar environment */

<noinclude>{{GoogleTrans-en}}{{TeamHeader|Activity Team}}</noinclude>{{TOCright}}

==Getting started in Activity development==
If you have no experience developing Sugar activities, these resources will help get you started.

====Setting up a Sugar environment====
If you use Linux, your best bet is to install [[Development Team/Jhbuild|sugar-jhbuild]]. You will be able to develop in your native environment, treating Sugar as just another desktop application.

If you run MacOS X or Windows, you will need to set up an emulator like VirtualBox. For setup instructions and links to pre-configured virtual machines, see http://wiki.sugarlabs.org/go/VirtualBox.

To develop efficiently using an emulator or a secondary machine (such as an OLPC XO), find an editor which supports editing files over a SFTP connection. [http://www.openkomodo.com/ Komodo Edit] with the Remote Drive Tree extension is a good example.

====Python Reference & Tutorials====
* http://docs.python.org/
* http://diveintopython.org/
* [http://pleac.sourceforge.net/pleac_python/index.html PLEAC - Programming Language Examples Alike Cookbook]

Python is the language Sugar is written in and is also used by most activities. If you don't already know Python well, you should familiarize yourself with it before continuing.

====PyGTK Reference & Tutorials====
* http://www.pygtk.org/docs/pygtk/index.html
* http://www.pygtk.org/docs/pygobject/index.html

PyGTK is the user interface toolkit used by Sugar activities. Bookmark these two links as you will reference them frequently during development.

* http://www.pygtk.org/pygtk2tutorial/index.html

The following sections of the PyGTK tutorial are most relevant to activity development.

* 1. Introduction
* 2. Getting Started
* 3. Moving On
* 4. Packing Widgets
* 5. Widget Overview
* 6. The Button Widget
* 7. Adjustments
* 8. Range Widgets
* 9. Miscellaneous Widgets
* 10. Container Widgets
* 12. Drawing Area

====Sugar Activities====
* [[Development Team/Almanac|Sugar Almanac]]

The Sugar Almanac contains all the information you need to start writing Sugar activities, ranging from directory structure to bundle format to API reference. It also contains answers to common questions and examples of common tasks.

* http://api.sugarlabs.org/

This automatically updated site contains the official API documentation for Sugar. Though it is currently quite sparse, the source code is included with the documentation and it's useful to have that at your fingertips.

====Cairo Graphics====
* http://www.tortall.net/mu/wiki/CairoTutorial

Cairo is the graphics library used in Sugar. The tutorial is a good introduction to the API as well as vector graphics programming in general.

====Pygame====
* http://www.pygame.org/
* [[Development_Team/sugargame]]

Pygame is a library for developing 2D sprite-based games using Python. Sugargame is a package which makes it possible to embed Pygame into a Sugar activity.

====Sugar [[Human Interface Guidelines]] (HIG)====
* [[Human Interface Guidelines]].

Required reading before planning the user interface for your activity. These pages give a good introduction to the thought process behind the Sugar environment and will help a lot when designing your activity.

====i18n (Localisation) Best Practices====
* [[Translation_Team/i18n_Best_Practices]].

Once you have strings in your Activity, here are some general tips which will make your translators happy :-)

====JSON introduction====
* http://www.json.org/fatfree.html

JSON is a data format commonly used to store activity data in the Journal.

* http://simplejson.googlecode.com/svn/tags/simplejson-2.0.8/docs/index.html

Currently, the recommended JSON library is simplejson. It has also become the standard JSON library in Python 2.6+.

NOTE: There is an odd thing about simplejson - in python25 it lives in ''simplejson'' module, but in python26 it uses ''json'' module. So, use something like [http://git.sugarlabs.org/projects/sugar-port/repos/mainline/blobs/master/json.py this] to wrap it.

====Git introduction====
Git is the version control software used by Sugar Labs. It is a distributed version control system and is quite powerful, but requires a lot of command line use.

* [[Activity Team/Git|Git]]

====XML routines====
There are [http://docs.python.org/library/markup.html dozens] Python classes to satisfy the XML standard, but if you want just save/load parameters use "Zen of XML" in Python - [http://effbot.org/zone/element.htm ElementTree] library. It's supported out of the box in Python 2.5 (xml.etree.ElementTree module). In previous versions you'll have to install library by yourself.

But if you just need a simple configuration format to read/write Python objects, check out JSON instead.

====Speech synthesizing====
If you want to add a speech synthesizer for English and other languages, try the [[Development Team/gst-plugins-espeak|gst-plugins-espeak]] plugin for gstreamer.

==Activity Development Resources==
This is an open area for posting links related to activity development.

===Sample code===

* An example of [[Activity Team/Sample code/Ruler|a simple activity that uses Cairo graphics]]
* An [http://uclug.org/images/Sugar.odp OpenOffice presentation] that touches on many of the issues encountered by first-time Sugar developers. Some items covered are: What is Sugar and Sugar Labs; What are some development environments; Some Sugar specific python statements for a PyGTK activity; Activity distribution. You can also [http://media.libsyn.com/media/dsyates/101309uclug0020.ogg listen] to the creator ([http://wiki.sugarlabs.org/go/User:Ossfm ossfm]) give the presentation at a LUG meeting (starting at 9 minutes and 55 seconds).

===References===
* http://docs.python.org/ The official Python documentation.
* http://www.pygtk.org/docs/pygtk/index.html PyGTK API reference
* http://www.pygtk.org/docs/pygobject/index.html PyGObject API reference. Contains a few important things missing from the PyGTK API such as timers and idle callbacks.
* http://api.sugarlabs.org/ The official Sugar API documentation (quite sparse but includes all the source code).
* [[Development Team/Almanac]] Detailed Sugar API overview. Quite in depth and offers answers to common questions.
* http://pygstdocs.berlios.de/ Python GStreamer bindings.
* [[Human Interface Guidelines]] The design behind the Sugar interface. Very important to read and understand before planning your activity's user interface.
* http://cairographics.org/documentation/pycairo/ Cairo Python API reference. Very sparse, use the tutorial instead.
* [[OLPC:Low-level Activity API]] Information on how activities interact with Sugar.
* http://www.pygame.org/ The Pygame game development library.
* [[Development Team/sugargame]] Python package which makes it possible to embed Pygame in a Sugar activity.

===Tutorials and Whitepapers===
* http://diveintopython.org/ An online book which teaches Python step by step.
* http://www.pygtk.org/pygtk2tutorial/index.html A very informative step-by-step introduction to PyGTK.
* http://www.olpcaustria.org/mediawiki/index.php/Activity_handbook Introduction to activity development by OLPC Austria.
* [[OLPC:Sugar Activity Tutorial]] Another introduction to activity development.
* http://www.tortall.net/mu/wiki/CairoTutorial A great introduction to Cairo in PyGTK and vector graphics drawing in general.
* http://www.json.org/fatfree.html An overview of the JSON data format.
* http://simplejson.googlecode.com/svn/tags/simplejson-2.0.8/docs/index.html Documentation for the recommended JSON library.
* [[OLPC:Shared Sugar Activities]] High level overview of collaboration.
* [[OLPC:Collaboration Tutorial]] Step by step tutorial on integrating collaboration into an activity.
* [[Activity_Team/Modifing_an_Activity]] Information describing simple modifications that can be made to common Sugar activities.
* [[Activity Team/Compatibility Tips]] Information on ensuring your activity is portable to the various distributions that run Sugar.

===Community resources===
* http://dev.sugarlabs.org/ Bug tracking for Sugar and activities. Go here to report bugs in the Sugar toolkit. Each activity should have its own component here.
* http://git.sugarlabs.org/ Gitorious source code hosting.
* http://git.sugarlabs.org/events.atom RSS feed of all Sugar development activity. Great for keeping an eye on the project as a whole.

===Non-English resources===
* http://sites.google.com/site/sugaractivities/ Spanish language activity development site in Uruguay.

==Stuck?==

If you have a question, don't hesitate to ask the activity team. We are happy to help and can often save you a lot of hunting for answers.

We hang out in #sugar on irc.freenode.net, and you can always [http://lists.sugarlabs.org/listinfo/sugar-devel subscribe] and post questions to sugar-devel@lists.sugarlabs.org.

[[Category:Activity Team]]
[[Category:Resource]]

Activity Team/Resources

2009-12-09T20:36:58Z

Wade: /* Setting up a Sugar environment */

<noinclude>{{GoogleTrans-en}}{{TeamHeader|Activity Team}}</noinclude>{{TOCright}}

==Getting started in Activity development==
If you have no experience developing Sugar activities, these resources will help get you started.

====Setting up a Sugar environment====
If you use Linux, your best bet is to install [[Development Team/Jhbuild|sugar-jhbuild]]. You will be able to develop in your native environment, treating Sugar as just another desktop application.

If you run MacOS X or Windows, you will need to set up an emulator like VirtualBox. For setup instructions and links to pre-configured virtual machines, see http://wiki.sugarlabs.org/go/VirtualBox.

To develop efficiently using an emulator or a secondary machine (such as an OLPC XO), find an editor which supports editing files over a SFTP connection. [http://www.openkomodo.com/ Komodo Edit] is a good example.

====Python Reference & Tutorials====
* http://docs.python.org/
* http://diveintopython.org/
* [http://pleac.sourceforge.net/pleac_python/index.html PLEAC - Programming Language Examples Alike Cookbook]

Python is the language Sugar is written in and is also used by most activities. If you don't already know Python well, you should familiarize yourself with it before continuing.

====PyGTK Reference & Tutorials====
* http://www.pygtk.org/docs/pygtk/index.html
* http://www.pygtk.org/docs/pygobject/index.html

PyGTK is the user interface toolkit used by Sugar activities. Bookmark these two links as you will reference them frequently during development.

* http://www.pygtk.org/pygtk2tutorial/index.html

The following sections of the PyGTK tutorial are most relevant to activity development.

* 1. Introduction
* 2. Getting Started
* 3. Moving On
* 4. Packing Widgets
* 5. Widget Overview
* 6. The Button Widget
* 7. Adjustments
* 8. Range Widgets
* 9. Miscellaneous Widgets
* 10. Container Widgets
* 12. Drawing Area

====Sugar Activities====
* [[Development Team/Almanac|Sugar Almanac]]

The Sugar Almanac contains all the information you need to start writing Sugar activities, ranging from directory structure to bundle format to API reference. It also contains answers to common questions and examples of common tasks.

* http://api.sugarlabs.org/

This automatically updated site contains the official API documentation for Sugar. Though it is currently quite sparse, the source code is included with the documentation and it's useful to have that at your fingertips.

====Cairo Graphics====
* http://www.tortall.net/mu/wiki/CairoTutorial

Cairo is the graphics library used in Sugar. The tutorial is a good introduction to the API as well as vector graphics programming in general.

====Pygame====
* http://www.pygame.org/
* [[Development_Team/sugargame]]

Pygame is a library for developing 2D sprite-based games using Python. Sugargame is a package which makes it possible to embed Pygame into a Sugar activity.

====Sugar [[Human Interface Guidelines]] (HIG)====
* [[Human Interface Guidelines]].

Required reading before planning the user interface for your activity. These pages give a good introduction to the thought process behind the Sugar environment and will help a lot when designing your activity.

====i18n (Localisation) Best Practices====
* [[Translation_Team/i18n_Best_Practices]].

Once you have strings in your Activity, here are some general tips which will make your translators happy :-)

====JSON introduction====
* http://www.json.org/fatfree.html

JSON is a data format commonly used to store activity data in the Journal.

* http://simplejson.googlecode.com/svn/tags/simplejson-2.0.8/docs/index.html

Currently, the recommended JSON library is simplejson. It has also become the standard JSON library in Python 2.6+.

NOTE: There is an odd thing about simplejson - in python25 it lives in ''simplejson'' module, but in python26 it uses ''json'' module. So, use something like [http://git.sugarlabs.org/projects/sugar-port/repos/mainline/blobs/master/json.py this] to wrap it.

====Git introduction====
Git is the version control software used by Sugar Labs. It is a distributed version control system and is quite powerful, but requires a lot of command line use.

* [[Activity Team/Git|Git]]

====XML routines====
There are [http://docs.python.org/library/markup.html dozens] Python classes to satisfy the XML standard, but if you want just save/load parameters use "Zen of XML" in Python - [http://effbot.org/zone/element.htm ElementTree] library. It's supported out of the box in Python 2.5 (xml.etree.ElementTree module). In previous versions you'll have to install library by yourself.

But if you just need a simple configuration format to read/write Python objects, check out JSON instead.

====Speech synthesizing====
If you want to add a speech synthesizer for English and other languages, try the [[Development Team/gst-plugins-espeak|gst-plugins-espeak]] plugin for gstreamer.

==Activity Development Resources==
This is an open area for posting links related to activity development.

===Sample code===

* An example of [[Activity Team/Sample code/Ruler|a simple activity that uses Cairo graphics]]
* An [http://uclug.org/images/Sugar.odp OpenOffice presentation] that touches on many of the issues encountered by first-time Sugar developers. Some items covered are: What is Sugar and Sugar Labs; What are some development environments; Some Sugar specific python statements for a PyGTK activity; Activity distribution. You can also [http://media.libsyn.com/media/dsyates/101309uclug0020.ogg listen] to the creator ([http://wiki.sugarlabs.org/go/User:Ossfm ossfm]) give the presentation at a LUG meeting (starting at 9 minutes and 55 seconds).

===References===
* http://docs.python.org/ The official Python documentation.
* http://www.pygtk.org/docs/pygtk/index.html PyGTK API reference
* http://www.pygtk.org/docs/pygobject/index.html PyGObject API reference. Contains a few important things missing from the PyGTK API such as timers and idle callbacks.
* http://api.sugarlabs.org/ The official Sugar API documentation (quite sparse but includes all the source code).
* [[Development Team/Almanac]] Detailed Sugar API overview. Quite in depth and offers answers to common questions.
* http://pygstdocs.berlios.de/ Python GStreamer bindings.
* [[Human Interface Guidelines]] The design behind the Sugar interface. Very important to read and understand before planning your activity's user interface.
* http://cairographics.org/documentation/pycairo/ Cairo Python API reference. Very sparse, use the tutorial instead.
* [[OLPC:Low-level Activity API]] Information on how activities interact with Sugar.
* http://www.pygame.org/ The Pygame game development library.
* [[Development Team/sugargame]] Python package which makes it possible to embed Pygame in a Sugar activity.

===Tutorials and Whitepapers===
* http://diveintopython.org/ An online book which teaches Python step by step.
* http://www.pygtk.org/pygtk2tutorial/index.html A very informative step-by-step introduction to PyGTK.
* http://www.olpcaustria.org/mediawiki/index.php/Activity_handbook Introduction to activity development by OLPC Austria.
* [[OLPC:Sugar Activity Tutorial]] Another introduction to activity development.
* http://www.tortall.net/mu/wiki/CairoTutorial A great introduction to Cairo in PyGTK and vector graphics drawing in general.
* http://www.json.org/fatfree.html An overview of the JSON data format.
* http://simplejson.googlecode.com/svn/tags/simplejson-2.0.8/docs/index.html Documentation for the recommended JSON library.
* [[OLPC:Shared Sugar Activities]] High level overview of collaboration.
* [[OLPC:Collaboration Tutorial]] Step by step tutorial on integrating collaboration into an activity.
* [[Activity_Team/Modifing_an_Activity]] Information describing simple modifications that can be made to common Sugar activities.
* [[Activity Team/Compatibility Tips]] Information on ensuring your activity is portable to the various distributions that run Sugar.

===Community resources===
* http://dev.sugarlabs.org/ Bug tracking for Sugar and activities. Go here to report bugs in the Sugar toolkit. Each activity should have its own component here.
* http://git.sugarlabs.org/ Gitorious source code hosting.
* http://git.sugarlabs.org/events.atom RSS feed of all Sugar development activity. Great for keeping an eye on the project as a whole.

===Non-English resources===
* http://sites.google.com/site/sugaractivities/ Spanish language activity development site in Uruguay.

==Stuck?==

If you have a question, don't hesitate to ask the activity team. We are happy to help and can often save you a lot of hunting for answers.

We hang out in #sugar on irc.freenode.net, and you can always [http://lists.sugarlabs.org/listinfo/sugar-devel subscribe] and post questions to sugar-devel@lists.sugarlabs.org.

[[Category:Activity Team]]
[[Category:Resource]]

Activity Team/Resources

2009-12-09T20:34:14Z

Wade: /* Activity Development Resources */

<noinclude>{{GoogleTrans-en}}{{TeamHeader|Activity Team}}</noinclude>{{TOCright}}

==Getting started in Activity development==
If you have no experience developing Sugar activities, these resources will help get you started.

====Setting up a Sugar environment====
If you use Linux, your best bet is to install [[Development Team/Jhbuild|sugar-jhbuild]]. You will be able to develop in your native environment, treating Sugar as just another desktop application.

If you run MacOS X or Windows, you will need to set up an emulator. For Mac OS X, see [[Supported_systems/Mac]]. For Windows, see [[Supported_systems/Windows]].

To develop efficiently using an emulator or a secondary machine running Sugar natively (such as an OLPC XO), find an editor which supports editing files over a SFTP connection. [http://www.openkomodo.com/ Komodo Edit] is a good example.

====Python Reference & Tutorials====
* http://docs.python.org/
* http://diveintopython.org/
* [http://pleac.sourceforge.net/pleac_python/index.html PLEAC - Programming Language Examples Alike Cookbook]

Python is the language Sugar is written in and is also used by most activities. If you don't already know Python well, you should familiarize yourself with it before continuing.

====PyGTK Reference & Tutorials====
* http://www.pygtk.org/docs/pygtk/index.html
* http://www.pygtk.org/docs/pygobject/index.html

PyGTK is the user interface toolkit used by Sugar activities. Bookmark these two links as you will reference them frequently during development.

* http://www.pygtk.org/pygtk2tutorial/index.html

The following sections of the PyGTK tutorial are most relevant to activity development.

* 1. Introduction
* 2. Getting Started
* 3. Moving On
* 4. Packing Widgets
* 5. Widget Overview
* 6. The Button Widget
* 7. Adjustments
* 8. Range Widgets
* 9. Miscellaneous Widgets
* 10. Container Widgets
* 12. Drawing Area

====Sugar Activities====
* [[Development Team/Almanac|Sugar Almanac]]

The Sugar Almanac contains all the information you need to start writing Sugar activities, ranging from directory structure to bundle format to API reference. It also contains answers to common questions and examples of common tasks.

* http://api.sugarlabs.org/

This automatically updated site contains the official API documentation for Sugar. Though it is currently quite sparse, the source code is included with the documentation and it's useful to have that at your fingertips.

====Cairo Graphics====
* http://www.tortall.net/mu/wiki/CairoTutorial

Cairo is the graphics library used in Sugar. The tutorial is a good introduction to the API as well as vector graphics programming in general.

====Pygame====
* http://www.pygame.org/
* [[Development_Team/sugargame]]

Pygame is a library for developing 2D sprite-based games using Python. Sugargame is a package which makes it possible to embed Pygame into a Sugar activity.

====Sugar [[Human Interface Guidelines]] (HIG)====
* [[Human Interface Guidelines]].

Required reading before planning the user interface for your activity. These pages give a good introduction to the thought process behind the Sugar environment and will help a lot when designing your activity.

====i18n (Localisation) Best Practices====
* [[Translation_Team/i18n_Best_Practices]].

Once you have strings in your Activity, here are some general tips which will make your translators happy :-)

====JSON introduction====
* http://www.json.org/fatfree.html

JSON is a data format commonly used to store activity data in the Journal.

* http://simplejson.googlecode.com/svn/tags/simplejson-2.0.8/docs/index.html

Currently, the recommended JSON library is simplejson. It has also become the standard JSON library in Python 2.6+.

NOTE: There is an odd thing about simplejson - in python25 it lives in ''simplejson'' module, but in python26 it uses ''json'' module. So, use something like [http://git.sugarlabs.org/projects/sugar-port/repos/mainline/blobs/master/json.py this] to wrap it.

====Git introduction====
Git is the version control software used by Sugar Labs. It is a distributed version control system and is quite powerful, but requires a lot of command line use.

* [[Activity Team/Git|Git]]

====XML routines====
There are [http://docs.python.org/library/markup.html dozens] Python classes to satisfy the XML standard, but if you want just save/load parameters use "Zen of XML" in Python - [http://effbot.org/zone/element.htm ElementTree] library. It's supported out of the box in Python 2.5 (xml.etree.ElementTree module). In previous versions you'll have to install library by yourself.

But if you just need a simple configuration format to read/write Python objects, check out JSON instead.

====Speech synthesizing====
If you want to add a speech synthesizer for English and other languages, try the [[Development Team/gst-plugins-espeak|gst-plugins-espeak]] plugin for gstreamer.

==Activity Development Resources==
This is an open area for posting links related to activity development.

===Sample code===

* An example of [[Activity Team/Sample code/Ruler|a simple activity that uses Cairo graphics]]
* An [http://uclug.org/images/Sugar.odp OpenOffice presentation] that touches on many of the issues encountered by first-time Sugar developers. Some items covered are: What is Sugar and Sugar Labs; What are some development environments; Some Sugar specific python statements for a PyGTK activity; Activity distribution. You can also [http://media.libsyn.com/media/dsyates/101309uclug0020.ogg listen] to the creator ([http://wiki.sugarlabs.org/go/User:Ossfm ossfm]) give the presentation at a LUG meeting (starting at 9 minutes and 55 seconds).

===References===
* http://docs.python.org/ The official Python documentation.
* http://www.pygtk.org/docs/pygtk/index.html PyGTK API reference
* http://www.pygtk.org/docs/pygobject/index.html PyGObject API reference. Contains a few important things missing from the PyGTK API such as timers and idle callbacks.
* http://api.sugarlabs.org/ The official Sugar API documentation (quite sparse but includes all the source code).
* [[Development Team/Almanac]] Detailed Sugar API overview. Quite in depth and offers answers to common questions.
* http://pygstdocs.berlios.de/ Python GStreamer bindings.
* [[Human Interface Guidelines]] The design behind the Sugar interface. Very important to read and understand before planning your activity's user interface.
* http://cairographics.org/documentation/pycairo/ Cairo Python API reference. Very sparse, use the tutorial instead.
* [[OLPC:Low-level Activity API]] Information on how activities interact with Sugar.
* http://www.pygame.org/ The Pygame game development library.
* [[Development Team/sugargame]] Python package which makes it possible to embed Pygame in a Sugar activity.

===Tutorials and Whitepapers===
* http://diveintopython.org/ An online book which teaches Python step by step.
* http://www.pygtk.org/pygtk2tutorial/index.html A very informative step-by-step introduction to PyGTK.
* http://www.olpcaustria.org/mediawiki/index.php/Activity_handbook Introduction to activity development by OLPC Austria.
* [[OLPC:Sugar Activity Tutorial]] Another introduction to activity development.
* http://www.tortall.net/mu/wiki/CairoTutorial A great introduction to Cairo in PyGTK and vector graphics drawing in general.
* http://www.json.org/fatfree.html An overview of the JSON data format.
* http://simplejson.googlecode.com/svn/tags/simplejson-2.0.8/docs/index.html Documentation for the recommended JSON library.
* [[OLPC:Shared Sugar Activities]] High level overview of collaboration.
* [[OLPC:Collaboration Tutorial]] Step by step tutorial on integrating collaboration into an activity.
* [[Activity_Team/Modifing_an_Activity]] Information describing simple modifications that can be made to common Sugar activities.
* [[Activity Team/Compatibility Tips]] Information on ensuring your activity is portable to the various distributions that run Sugar.

===Community resources===
* http://dev.sugarlabs.org/ Bug tracking for Sugar and activities. Go here to report bugs in the Sugar toolkit. Each activity should have its own component here.
* http://git.sugarlabs.org/ Gitorious source code hosting.
* http://git.sugarlabs.org/events.atom RSS feed of all Sugar development activity. Great for keeping an eye on the project as a whole.

===Non-English resources===
* http://sites.google.com/site/sugaractivities/ Spanish language activity development site in Uruguay.

==Stuck?==

If you have a question, don't hesitate to ask the activity team. We are happy to help and can often save you a lot of hunting for answers.

We hang out in #sugar on irc.freenode.net, and you can always [http://lists.sugarlabs.org/listinfo/sugar-devel subscribe] and post questions to sugar-devel@lists.sugarlabs.org.

[[Category:Activity Team]]
[[Category:Resource]]

Activities/Typing Turtle

2009-11-22T18:51:27Z

Wade: /* Typing Turtle */

<noinclude>{{GoogleTrans-en}}{{TOCright}}
[[Category:Activities|Typing Turtle]]</noinclude>

==Typing Turtle==

Typing Turtle is available from the Sugar Labs Activity Library: http://activities.sugarlabs.org/en-US/sugar/addon/4026.

Typing Turtle is an interactive touch typing program. It gradually introduces the keys on the keyboard through a series of lessons, until the student has learned the entire keyboard. Skills are reinforced with typing games.

===Screenshots===
Screenshots can be found at the [http://activities.sugarlabs.org/en-US/sugar/addon/4026 Activity page].

===Features===
* An on-screen keyboard with overlaid hand positions shows the correct way to press each key, encouraging good typing habits.
* Automatically picks up and uses the system's keyboard layout.
* You can make your own lessons, and send them to students or friends.
* A balloon game provides an entertaining way to gain skill.
* Medals are awarded as the user completes the lessons. Gold is for the best accuracy and speed, followed by Silver and Bronze.

===Localizing Typing Turtle===
As with any other Sugar activity, Typing Turtle is translated using [translate.sugarlabs.org Pootle]. Pootle displays the translatable strings from the newest version of the activity and allows them to be translated into a different language. When translations are saved, the author is notified and will then release a new version to activities.sugarlabs.org with the new translations.

Typing Turtle's lesson content is too complex to be translated the same way, and must be created from scratch for each language and keyboard layout. Use the lesson editor feature to create a new set of lessons for your language and keyboard layout, export the lessons to the Journal, and email them to the author. They will be included in the next version.

Development Team/Sugargame

2009-11-21T17:44:29Z

Wade: /* Sugargame */

== Sugargame ==

Sugargame is a Python package which allows [http://www.pygame.org/ Pygame]
programs to run well under Sugar.
It is fork of the olcpgames framework, which is no longer maintained.

http://git.sugarlabs.org/projects/sugargame

What it does:

* Wraps a Sugar activity around an existing Pygame program with few changes
* Allows Sugar toolbars and other widgets to be added to the activity UI
* Provides hooks for saving to and restoring from the Journal

==== Differences between Sugargame and olpcgames ====

The olpcgames framework provides a wrapper around Pygame which attempts to
allow a Pygame program to run mostly unmodified under Sugar. To this end,
the Pygame program is run in a separate thread with its own Pygame message
loop while the main thread runs the GTK message loop. Also, olpcgames wraps
Sugar APIs such as the journal and mesh into a Pygame-like API.

Sugargame takes a simpler approach; it provides a way to embed Pygame into a
GTK widget. The Sugar APIs are used to interact with Sugar, the Pygame APIs
are used for the game.

Sugargame advantages:

* Simpler code
* More elegant interface between Pygame and GTK
* Runs as a single thread: no thread related segfaults
* Possible to use Sugar widgets with Pygame

Sugargame limitations:

* No support for Pango or SVG sprites (yet)

== Using Sugargame ==

See also [[Development Team/Sugargame/Examples]].

==== Wrapping a Pygame program ====

To use Sugargame to Sugarize a Pygame program, set up an activity directory and
copy the Sugargame package to it.

The activity directory should look something like this:

activity/ - Activity directory: activity.info, SVG icon, etc.
sugargame/ - Sugargame package
MyActivity.py - Activity class
mygame.py - Pygame code
setup.py - Install script

To make the Activity class, start with test/TestActivity.py from the Sugargame
distribution.

The activity should create a single PygameCanvas widget and call run_pygame on it.
Pass the main loop function of the Pygame program.

self._canvas = sugargame.canvas.PygameCanvas(self)
self.set_canvas(self._canvas)

# Start the game running.
self._canvas.run_pygame(self.game.run)

In your Pygame main loop, pump the GTK message loop:

while gtk.events_pending():
gtk.main_iteration()

==== Adding Pygame to a PyGTK activity ====

To add Pygame to an existing Sugar activity, create a PygameCanvas widget and call
run_pygame on it.

widget = sugargame.canvas.PygameCanvas(self)
vbox.pack_start(widget)

widget.run_pygame(self.game.run)

Due to limitations of Pygame and SDL, there can only be one PygameCanvas in the
entire activity.

The argument to run_pygame is a function structured like a Pygame program. In the
main loop, remember to dispatch GTK messages using gtk.main_iteration().

def main_loop():
clock = pygame.time.Clock()
screen = pygame.display.get_surface()

while self.running:
# Pump GTK messages.
while gtk.events_pending():
gtk.main_iteration()

# Pump PyGame messages.
for event in pygame.event.get():
if event.type == pygame.QUIT:
return
elif event.type == pygame.VIDEORESIZE:
pygame.display.set_mode(event.size, pygame.RESIZABLE)

# Clear Display
screen.fill((255,255,255)) #255 for white

# Draw stuff here
.................

# Flip Display
pygame.display.flip()

# Try to stay at 30 FPS
self.clock.tick(30)

== Support ==

For help with Sugargame, please email the Sugar Labs development list:

: sugar-devel@lists.sugarlabs.org

Sugargame is developed by Wade Brainerd <wadetb@gmail.com>.

It is loosely based on the source code to the olpcgames framework, developed by
the One Laptop Per Child project.

=== Changelog ===

====v1.0====
Initial version of Sugargame

Development Team/Sugargame/Examples

2009-11-21T17:25:03Z

Wade: /* TestGame.py */

== Bouncing Ball ==

This is a simple Sugargame example which bounces a red ball across the screen.

A Sugar toolbar provides Pause and Unpause functionality, demonstrating communication between Sugar and Pygame.

====TestActivity.py====

This file implements the TestActivity activity class. The constructor sets up the Pygame canvas and Sugar toolbar, and starts the game running.

from gettext import gettext as _

import sys
import gtk
import pygame

import sugar.activity.activity
import sugar.graphics.toolbutton

sys.path.append('..') # Import sugargame package from top directory.
import sugargame.canvas

import TestGame

class TestActivity(sugar.activity.activity.Activity):
def __init__(self, handle):
super(TestActivity, self).__init__(handle)

self.paused = False

# Create the game instance.
self.game = TestGame.TestGame()

# Build the activity toolbar.
self.build_toolbar()

# Build the Pygame canvas.
self._canvas = sugargame.canvas.PygameCanvas(self)
# Note that set_canvas implicitly calls read_file when resuming from the Journal.
self.set_canvas(self._canvas)

# Start the game running.
self._canvas.run_pygame(self.game.run)

def build_toolbar(self):
stop_play = sugar.graphics.toolbutton.ToolButton('media-playback-stop')
stop_play.set_tooltip(_("Stop"))
stop_play.set_accelerator(_('<ctrl>space'))
stop_play.connect('clicked', self._stop_play_cb)

toolbar = gtk.Toolbar()
toolbar.insert(stop_play, 0)
toolbar.insert(gtk.SeparatorToolItem(), 1)

toolbox = sugar.activity.activity.ActivityToolbox(self)
toolbox.add_toolbar(_("Pygame"), toolbar)

toolbox.show_all()
self.set_toolbox(toolbox)

def _stop_play_cb(self, button):
# Pause or unpause the game.
self.paused = not self.paused
self.game.set_paused(self.paused)

# Update the button to show the next action.
if self.paused:
button.set_icon('media-playback-start')
button.set_tooltip(_("Start"))
else:
button.set_icon('media-playback-stop')
button.set_tooltip(_("Stop"))

def read_file(self, file_path):
self.game.read_file(file_path)

def write_file(self, file_path):
self.game.write_file(file_path)

====TestGame.py====

This file implements the game (really just a bouncing ball animation). Note the main function at the end; this file can also be run as a standalone Pygame program.

#!/usr/bin/python
import pygame
import gtk

class TestGame:
def __init__(self):
# Set up a clock for managing the frame rate.
self.clock = pygame.time.Clock()

self.x = -100
self.y = 100

self.vx = 10
self.vy = 0

self.paused = False

def set_paused(self, paused):
self.paused = paused

# Called to save the state of the game to the Journal.
def write_file(self, file_path):
pass

# Called to load the state of the game from the Journal.
def read_file(self, file_path):
pass

# The main game loop.
def run(self):
self.running = True

screen = pygame.display.get_surface()

while self.running:
# Pump GTK messages.
while gtk.events_pending():
gtk.main_iteration()

# Pump PyGame messages.
for event in pygame.event.get():
if event.type == pygame.QUIT:
return
elif event.type == pygame.VIDEORESIZE:
pygame.display.set_mode(event.size, pygame.RESIZABLE)

# Move the ball
if not self.paused:
self.x += self.vx
if self.x > screen.get_width() + 100:
self.x = -100

self.y += self.vy
if self.y > screen.get_height() - 100:
self.y = screen.get_height() - 100
self.vy = -self.vy

self.vy += 5;

# Clear Display
screen.fill((255,255,255)) #255 for white

# Draw the ball
pygame.draw.circle(screen, (255,0,0), (self.x, self.y), 100)

# Flip Display
pygame.display.flip()

# Try to stay at 30 FPS
self.clock.tick(30)

# This function is called when the game is run directly from the command line:
# ./TestGame.py
def main():
pygame.init()
pygame.display.set_mode((0, 0), pygame.RESIZABLE)
game = TestGame()
game.run()

if __name__ == '__main__':
main()

Development Team/Sugargame/Examples

2009-11-21T17:24:44Z

Wade: /* TestGame.py */

Activities/Typing Turtle

2009-11-19T04:34:03Z

Wade: Created page with '<noinclude>{{GoogleTrans-en}}{{TOCright}} Typing Turtle</noinclude> ==Typing Turtle== Typing Turtle is available from the Sugar Labs Activity Library: h…'

2009-10-17T02:31:16Z

Wade:

<noinclude>{{GoogleTrans-en}}{{TOCright}}</noinclude>

== Summary ==
The "Report a problem" control panel provides a way for the user to report issues with the Sugar shell and activities. The control panel uploads system information and logs, along with the user's description of the problem.

== Owner ==
* Name: [[User:Wade|Wade Brainerd]]
* Email: wadetb@gmail.com

== Current status ==
* Targeted release: 0.88
* Last updated: October 16th, 2009
* Percentage of completion: 90%

== Detailed Description ==
A new control panel will be added, titled "Report a problem". This panel contains a description box and an Upload report button. When the button is pressed, the description and system logs are uploaded to a central Sugar Labs server.

The central server logs the problem reports in a database and stores a copy of the logs. It also analyzes the logs for specific errors (such as Python Tracebacks). When a problem report is added, the server sends an email out to a mailing list of developers and interested parties.

When a problem is detected in an Activity, such as failure to launch, Sugar will offer a "Report problem" button which takes the user directly to the control panel.

After uploading, the user is given a Report ID number (a small decimal number). They can use this if they wish to follow up with the Sugar developers by email.

[[File:Problem-report.jpg]]

== Benefit to Sugar ==
Currently there is no mechanism for non-technical users to submit problem reports. In order to inform the Sugar or Activity developers of a problem, a user has two options:

* Create a Trac account and enter a bug.
* Write an email to sugar-devel@lists.sugarlabs.org.

The first option is time consuming and requires the user to fill in confusing fields such as Component and Version manually. The second option requires the user to have an email account, and the report is not logged anywhere. Neither option is convenient or provides relevant details about the problem.

The new control panel offers a way for casual users to report problems encountered in Sugar. It also supplies a high level of detail about the problem to the developers.

The reason problem reports are not added directly to Trac is that we don't want to spam the database with spurious reports. Problem reports are intended to be triaged by subscribers to the mailing list, and then either bugged or noted on an existing ticket.

== Scope ==
A prototype of the control panel and server have been finished and posted to [http://trac.sugarlabs.org/ticket/1439 #1439] as patches.

The collection server is currently running at logcollect.sugarlabs.org. Logs are emailed out to the sugar-reports@lists.sugarlabs.org mailing list.

Work left to do:
* <strike>The control panel needs a SVG icon.</strike> [[File:Toolbar-bug.png]]
* When an activity exits, if its log contains an exception report, Sugar should offer to report the problem. When an activity fails to launch, Sugar should display an error on the launch window and offer to report the problem instead of timing out.
* <strike>The server needs to be installed on the SugarLabs infrastructure and the reports mailing list needs to be created (sugar-reports@lists.sugarlabs.org?).</strike> The server is now live at logcollect.sugarlabs.org. The mailing list sugar-reports@lists.sugarlabs.org now exists.
* <strike>For deployments, there should be a way to override the server URL.</strike> The server URL now comes from Gconf.
* <strike>The Log activity needs to have its Upload Logs button replaced by a button that opens the control panel.</strike> Most likely we will remove the button from Log, but patches for both options have been posted to the ticket.

== How To Test ==
{{:{{PAGENAME}}/Testing}}

== User Experience ==
The user will notice a new control panel. When an activity fails to launch or otherwise suffers an exception, the user will be offered an opportunity to report the problem.

== Dependencies ==
None

== Contingency Plan ==
Nothing depends on this feature. If it's not ready in time it can simply be omitted.

== Documentation ==
Ideally this feature would be documented as part of the FLOSS manual.

== Release Notes ==
A mention of how to customize the server URL would be useful.

== Comments and Discussion ==
* See [[{{TALKPAGENAME}}|discussion tab for this feature]]

[[Category:Feature Page Incomplete]]
[[Category:Feature]]
----
''You can add categories to tie features back to real deployments/schools requesting them, for example <nowiki>[[</nowiki>Category:Features requested by School Xyz]]''