https://wiki.sugarlabs.org/api.php?action=feedcontributions&user=TuukkaH&feedformat=atomSugar Labs - User contributions [en]2024-03-29T10:07:19ZUser contributionsMediaWiki 1.35.2https://wiki.sugarlabs.org/index.php?title=Development_Team/Almanac&diff=39950Development Team/Almanac2009-11-06T21:37:36Z<p>TuukkaH: link to Sugar System Stack and Sugar Platform Stack</p>
<hr />
<div>{{Translations}}<br />
{{Almanac}}<br />
{{Almanac TOC}}<br />
== How do I get additional help beyond this almanac? ==<br />
* Looking to get started with the basics of Sugar development? Check out OLPC Austria's [http://wiki.sugarlabs.org/images/5/51/Activity_Handbook_200805_online.pdf Activity Handbook] (''Please note that this handbook was last updated in May 2008 so the screenshots still show pre-8.2 design. In terms of the code itself things should still work as described. If you run into any issues please contact [[User:ChristophD|ChristophD]].'') <br />
* See also [[Development Team/Almanac/Code Snippets]]<br />
<br />
<br />
Now, on to the actual almanac ...<br />
<br />
== Where can I see the components of Sugar and their relationships? ==<br />
* [[Sugar System Stack]]<br />
* [[Sugar Platform Stack]]<br />
<br />
== Where can I see API changes? ==<br />
API changes between OLPC releases can be seen here: [[Development Team/Almanac/API Changes|API Changes]]<br />
<br />
== Getting Started ==<br />
=== How do I structure my files so that they are a valid sugar activity? === <br />
Information on activity bundle structure can be found here: [[Development Team/Almanac/Activity Bundles|Activity Bundles]]<br />
<br />
=== How do I make an icon for my activity? ===<br />
Information on what you need to do can be found here: [[Development Team/Almanac/Making Icons|Making Icons]]<br />
<br />
== Package: sugar ==<br />
* [[Development Team/Almanac/sugar.env|sugar.env]]<br />
* [[Development Team/Almanac/sugar.profile|sugar.profile]]<br />
* [[Development Team/Almanac/sugar.mime|sugar.mime]]<br />
* [[Development Team/Almanac/sugar.logger|sugar.logger]]<br />
<br />
== Package: sugar.activity ==<br />
* [[Development Team/Almanac/sugar.activity.activity|sugar.activity.activity]]<br />
* [[Development Team/Almanac/sugar.activity.activityfactory|sugar.activity.activityfactory]]<br />
* [[Development Team/Almanac/sugar.activity.registry|sugar.activity.registry]]<br />
<br />
== Package: sugar.datastore ==<br />
* [[Development Team/Almanac/sugar.datastore.datastore|sugar.datastore.datastore]]<br />
<br />
== Package: sugar.graphics ==<br />
* [[Development Team/Almanac/sugar.graphics.alert|sugar.graphics.alert]]<br />
* [[Development Team/Almanac/sugar.graphics.icon|sugar.graphics.icon]]<br />
* [[Development Team/Almanac/sugar.graphics.notebook|sugar.graphics.notebook]]<br />
* [[Development Team/Almanac/sugar.graphics.toolbutton|sugar.graphics.toolbutton]]<br />
* [[Development Team/Almanac/sugar.graphics.toolbox|sugar.graphics.toolbox]]<br />
* [[Development Team/Almanac/sugar.graphics.style|sugar.graphics.style]]<br />
<br />
== Package: sugar.presence ==<br />
* [[Development Team/Almanac/Sugar.presence|Sugar.presence]]<br />
* [[Development Team/Almanac/Sugar.presence.activity|Sugar.presence.activity]]<br />
* [[Development Team/Almanac/Sugar.presence.buddy|Sugar.presence.buddy]]<br />
* [[Development Team/Almanac/Sugar.presence.presenceservice|Sugar.presence.presenceservice]]<br />
<br />
== Clipboard ==<br />
* Notes on using [[Development Team/Almanac/GTK's Clipboard Module|GTK's Clipboard Module]]<br />
<br />
== Logging ==<br />
* [[Development Team/Almanac/sugar.logger|sugar.logger]]<br />
* Notes on using [[Development Team/Almanac/Python Standard Logging|Python Standard Logging]]<br />
<br />
== Internationalization ==<br />
*[[Development Team/Almanac/Internationalization|Internationalization]]<br />
<br />
== Text and Graphics for Sugar Activities ==<br />
* [[Development Team/Almanac/Pango|Pango]]<br />
=== How do I create a text box for code editing? ===<br />
You can use gtksourceview2<br />
<pre><br />
import gtk<br />
import gtksourceview2<br />
from sugar.graphics import style<br />
<br />
...<br />
<br />
# set up the buffer<br />
buffer = gtksourceview2.Buffer()<br />
if hasattr(buffer, 'set_highlight'): # handle different API versions<br />
buffer.set_highlight(True)<br />
else:<br />
buffer.set_highlight_syntax(True)<br />
<br />
# set mime type for the buffer<br />
lang_manager = gtksourceview2.language_manager_get_default()<br />
if hasattr(lang_manager, 'list_languages'): # again, handle different APIs<br />
langs = lang_manager.list_languages()<br />
else:<br />
lang_ids = lang_manager.get_language_ids()<br />
langs = [lang_manager.get_language(lang_id) <br />
for lang_id in lang_ids]<br />
for lang in langs:<br />
for m in lang.get_mime_types():<br />
if m == mime_type: # <-- this is the mime type you want<br />
buffer.set_language(lang)<br />
<br />
# set up the view object, use it like gtk.TextView<br />
view = gtksourceview2.View(buffer)<br />
view.set_size_request(300, 450)<br />
view.set_editable(True)<br />
view.set_cursor_visible(True)<br />
view.set_show_line_numbers(True)<br />
view.set_wrap_mode(gtk.WRAP_CHAR)<br />
view.set_right_margin_position(80)<br />
#view.set_highlight_current_line(True) #FIXME: Ugly color<br />
view.set_auto_indent(True)<br />
view.modify_font(pango.FontDescription("Monospace " +<br />
str(style.FONT_SIZE)))<br />
...<br />
<br />
</pre><br />
<br />
To set the text in the buffer:<br />
<pre><br />
buffer.set_text(text)<br />
</pre><br />
To get all the text:<br />
<pre><br />
text = buffer.get_text(buffer.get_start_iter(), buffer.get_end_iter())<br />
</pre><br />
<br />
You will probably want to put the view in a gtk.ScrolledWindow<br />
<pre><br />
sw = gtk.ScrolledWindow()<br />
sw.add(view)<br />
sw.set_policy(gtk.POLICY_AUTOMATIC, gtk.POLICY_AUTOMATIC)<br />
</pre><br />
and add the sw object instead of the view.<br />
<br />
<br />
You can find more in the Pippy source and in jarabe.view.sourceview.<br />
<br />
== Audio & Video ==<br />
* [[Development Team/Almanac/GStreamer|GStreamer]]<br />
<br />
== Mouse ==<br />
=== How do I change the mouse cursor in my activity to the wait cursor? ===<br />
In your activity subclass:<br />
<br />
<pre><br />
self.window.set_cursor( gtk.gdk.Cursor(gtk.gdk.WATCH) )<br />
</pre><br />
<br />
and to switch it back to the default:<br />
<br />
<pre><br />
self.window.set_cursor( None );<br />
</pre><br />
<br />
=== How do I track the position of the mouse? ===<br />
There are many different reasons you might want to track the position of the mouse in your activity, ranging from the entertaining ([[http://en.wikipedia.org/wiki/Xeyes]]) to the functional (hiding certain windows when the mouse hasn't moved for a couple of seconds and making those ui elements re-appear when the mouse has moved again). Here is one way you can implement this functionality:<br />
<br />
<pre><br />
<br />
...<br />
self.hideWidgetsTime = time.time()<br />
self.mx = -1<br />
self.my = -1<br />
self.HIDE_WIDGET_TIMEOUT_ID = gobject.timeout_add( 500, self.mouseMightHaveMovedCb )<br />
<br />
def _mouseMightHaveMovedCb( self ):<br />
x, y = self.get_pointer()<br />
passedTime = 0<br />
<br />
if (x != self.mx or y != self.my):<br />
self.hideWidgetsTime = time.time()<br />
if (self.hiddenWidgets):<br />
self.showWidgets()<br />
self.hiddenWidgets = False<br />
else:<br />
passedTime = time.time() - self.hideWidgetsTime<br />
<br />
<br />
if (passedTime >= 3):<br />
if (not self.hiddenWidgets):<br />
self.hideWidgets()<br />
self.hiddenWidgets = True<br />
<br />
self.mx = x<br />
self.my = y<br />
return True<br />
<br />
</pre><br />
<br />
== Miscellaneous==<br />
<br />
The tasks below are random useful techniques that have come up as I write code and documentation for this reference. They have yet to be categorized, but will be as a sufficient set of related entries are written.<br />
<br />
<br />
=== How do I know when my activity is "active" or not? ===<br />
<br />
You can set an event using the VISIBILITY_NOTIFY_MASK constant in order to know when your activity changes visibility. Then in the callback for this event, you simply compare the event's state to gtk-defined variables for activity visibility. See the [http://www.pygtk.org/docs/pygtk/gdk-constants.html#gdk-visibility-state-constants GDK Visibility State Constants] section of gtk.gdk.Constants for more information. <br />
<br />
<pre><br />
# Notify when the visibility state changes by calling self.__visibility_notify_cb<br />
# (PUT THIS IN YOUR ACTIVITY CODE - EG. THE __init__() METHOD)<br />
self.add_events(gtk.gdk.VISIBILITY_NOTIFY_MASK)<br />
self.connect("visibility-notify-event", self.__visibility_notify_cb)<br />
...<br />
# Callback method for when the activity's visibility changes<br />
def __visibility_notify_cb(self, window, event):<br />
if event.state == gtk.gdk.VISIBILITY_FULLY_OBSCURED:<br />
print "I am not visible"<br />
elif event.state in [gtk.gdk.VISIBILITY_UNOBSCURED, gtk.gdk.VISIBILITY_PARTIAL]:<br />
print "I am visible"<br />
</pre><br />
<br />
=== How do I get the amount of free space available on disk under the /home directory tree? ===<br />
The following function uses the [http://docs.python.org/lib/module-statvfs.html statvfs] module. The following code demonstrates how to get the total amount of free space under /home. <br />
<br />
<pre><br />
#### Method: getFreespaceKb, returns the available freespace in kilobytes. <br />
def getFreespaceKb(self):<br />
stat = os.statvfs("/home")<br />
freebytes = stat[statvfs.F_BSIZE] * stat[statvfs.F_BAVAIL]<br />
freekb = freebytes / 1024<br />
return freekb<br />
</pre><br />
<br />
Note, however, that assuming anything about "/home" is a bad idea, better use os.environ['HOME'] instead. Rainbow will put your actual files elsewhere,<br />
some on ramdisks, some on flash. Be clear about which filesystem's free space you actually care about.<br />
<br />
=== How do I know whether my activity is running on a physical XO? ===<br />
Sugar runs on ordinary computers as well as on XO's. While your activity is typically going to be run on a real XO, some people will indeed run it elsewhere. Normally you shouldn't write your activity to care whether it's on an XO or not. If for some odd reason, you need to care, the easiest way to tell if you are on a physical XO is to check whether /sys/power/olpc-pm, an essential power management file for the XO, exists. <ref>[http://lists.laptop.org/pipermail/devel/2008-June/015923.html reliably detecting if running on an XO]</ref> <ref>OLPC [[olpc:Power Management Interface]]</ref><br />
<br />
<pre><br />
import os<br />
...<br />
#Print out a boolean value that tells us whether we are on an XO or not. <br />
print os.path.exists('/sys/power/olpc-pm')<br />
</pre><br />
<br />
=== How do I know the current language setting on my XO? ===<br />
The system variable 'LANG' tells you which language is currently active on the XO. The following code shows how to look at the value of this variable. <br />
<br />
<pre><br />
import os<br />
...<br />
_logger.debug(os.environ['LANG'])<br />
</pre><br />
<br />
=== How do I repeatedly call a specific method after N number of seconds? ===<br />
The gobject.timeout_add() function allows you to invoke a callback method after a certain amount of time. If you want to repeatedly call a method, simply keep invoking the gobject.timeout_add function in your callback itself. The code below is a simple example, where the callback function is named repeatedly_call. Note that the timing of the callbacks are approximate. To get the process going, you should make an initial call to repeatedly_call() somewhere in your code. <br />
<br />
You can see a more substantive example of this pattern in use when we [[olpc:Pango#How_do_I_dynamically_set_the_text_in_a_pango_layout.3F | regularly update the time displayed on a pango layout object]]. <br />
<br />
<pre><br />
<br />
#This method calls itself ROUGHLY every 1 second <br />
def repeatedly_call(self):<br />
now = datetime.datetime.now()<br />
gobject.timeout_add(self.repeat_period_msec, self.repeatedly_update_time)<br />
</pre><br />
<br />
<br />
=== How do I update the current build version of code that is running on my XO? ===<br />
<br />
There are several pages that give you instructions on how to install/update your current build. <br />
<br />
* If you already have a working build installed and an internet connection, first try [[olpc:olpc-update]]. <br />
* If that doesn't work, you can look at instructions for an [[olpc:Activated upgrade]] that can be done via USB] boot. <br />
<br />
As the instructions on the pages linked above note, make sure to install your activities separately after you have upgraded to a specific base build.<br />
<br />
<br />
=== I am developing on an XO laptop, but my keyboard and language settings are not ideal. How can I change them? ===<br />
<br />
Internationalized laptops will often have settings that might slow you down while developing. To change around the language settings so you can better understand environment messages, use the [[olpc:Sugar Control Panel]]<br />
<br />
Keyboard settings on internationalized laptops<ref>[[olpc:Keyboard layouts#OLPC keyboard layouts]]</ref> can also be suboptimal, especially as characters like "-" and "/" are in unfamiliar positions. You can use the <tt>setxkbmap</tt> command in the [[olpc:Terminal Activity]] to reset the type of keyboard input used and then attach a standard U.S. keyboard that will allow you to type normally. The command below sets the keyboard to the US mapping (it will reset to the default internationalized mapping upon restart). <br />
<br />
setxkbmap us<br />
<br />
=== My Python activity wants to use threads; how do I do that? ===<br />
<br />
A question that has been answered with limited success is which threading patterns are most appropriate for use in Sugar. The following pattern of code to work fine in basic instances:<br />
<br />
<pre><br />
#### Method: __init__, initialize this AnnotateActivity instance<br />
def __init__(self, handle):<br />
...<br />
self.sample_thread = Thread(target=self.announce_thread, args=())<br />
self.sample_thread.setDaemon(0)<br />
self.sample_thread.start()<br />
...<br />
<br />
def announce_thread(self):<br />
while (self.Running):<br />
time.sleep(1)<br />
print "thread running"<br />
self._update_chat_text("Thread", "In here")<br />
</pre><br />
<br />
This is the basic series of steps that most online documentation on python suggests to use when trying to work with threads in python. The problem is that it is unclear how this pattern relates to code that worked in the SimCity activity:<br />
<br />
<pre><br />
import gobject<br />
gobject.threads_init()<br />
#import dbus.mainloop.glib<br />
#dbus.mainloop.glib.threads_init()<br />
</pre><br />
<br />
It should be noted that in the SimCity activity the pygame sound player would not produce sound reliably unless this setup was done.<br />
<br />
<p><br />
<br />
Should the two patterns always be used in tandem? It seems that the latter code is mainly to initiate gobject and other libraries to work with threading, but it is unclear what restrictions there are with using threading with these libraries. Does one take precedence over the other? It is not clear if there is any problem with using the standard python threading code on the sugar technology stack.<br />
<br />
</p><br />
<br />
<p><br />
<br />
In fact, experiments with threading on sugar leads to several different problems. For one thing, thread termination was tricky - using the can_close() method for sugar activities to terminate an activity only killed threads in some circumstances. It did not properly handle terminating threads in the case of CTRL-C or terminal interrupts. You can try to catch signals (SIGINT, SIGTERM or SIGHUP), but you will still be running in to errors in terminating child threads using these as well. <br />
<br />
</p><br />
<br />
<p><br />
<br />
Another set of errors with threading comes up when trying to combine with stream tubes. The bottom line is that it is unclear what the scope of threading in a Sugar activity should be - should it simply work if you do the standard python threading pattern, is the use of the glib.threads_init and gobject.threads_init calls necessary, are there other interactions with threads and dbus that need to be accounted for? With more clarity from sugar developers on how the platform envisions threading to work in an activity, we can be more comfortable writing entries in the Almanac to help developers write error-free code.<br />
<br />
</p><br />
<br />
=== How do I customize the title that is displayed for each instance of my activity? ===<br />
<br />
By default, activity titles are just the generic activity names that you specify in your activity.info file. In some applications, you may want the activity title to be more dynamic. <br />
<br />
For example, it makes sense to set the title for different browser sessions to the active web page being visited. That way, when you look back in the journal at the different browser sessions you have run in the previous few days, you can identify unique sessions based on the website you happened to be visiting at the time. <br />
<br />
The code below shows how you can set the metadata for your activity to reflect a dynamic title based on whatever session criteria you feel is important. This example is adapted from the Browse activity, which sets activity instance titles based on the title of the current web page being visited. <br />
<br />
<pre><br />
if self.metadata['mime_type'] == 'text/plain':<br />
if not self._jobject.metadata['title_set_by_user'] == '1':<br />
if self._browser.props.title:<br />
# Set the title of this activity to be the current <br />
# title of the page being visited by the browser. <br />
self.metadata['title'] = self._browser.props.title<br />
</pre><br />
<br />
=== What packages are available on sugar to support game development? ===<br />
<br />
If your activity will require tools that are typically needed to develop robust and clean video games, then you should utilize the [http://www.pygame.org/ pygame package]. It can be readily imported into any activity:<br />
<br />
<pre><br />
import pygame<br />
...<br />
</pre><br />
<br />
=== How do I detect when one of the game buttons on the laptop have been pressed? ===<br />
<br />
The laptop game buttons (the circle, square, x, and check buttons next to the LCD) are encoded as page up, home, page down and end respectively. So, you can detect their press by listening for these specific events. For example, the code below listens for button presses and then just writes to an output widget which button was pressed. <br />
<br />
<pre><br />
...<br />
#### Initialize this activity. <br />
def __init__(self, handle):<br />
...<br />
self.connect('key-press-event', self._keyPressCb)<br />
...<br />
<br />
#### Method _keyPressCb, which catches any presses of the game buttons. <br />
def _keyPressCb(self, widget, event):<br />
<br />
keyname = gtk.gdk.keyval_name(event.keyval)<br />
<br />
if (keyname == 'KP_Page_Up'):<br />
self._chat += "\nCircle Pressed!"<br />
self._chat_buffer.set_text(self._chat)<br />
elif (keyname == 'KP_Page_Down'):<br />
self._chat += "\nX Pressed!"<br />
self._chat_buffer.set_text(self._chat)<br />
elif (keyname == 'KP_Home'):<br />
self._chat += "\nSquare Pressed!"<br />
self._chat_buffer.set_text(self._chat)<br />
elif (keyname == 'KP_End'):<br />
self._chat += "\nCheck Pressed!"<br />
self._chat_buffer.set_text(self._chat)<br />
<br />
return False<br />
</pre><br />
<br />
<br />
=== How do I detect if one of the joystick buttons has been pressed? ===<br />
<br />
This is the same process as detecting game buttons, except with different names for the keys. Again, you listen for "key-press-event" signals and then in your callback you check to see if the pressed button was one of the joystick keys. <br />
<br />
<pre><br />
#### Initialize this activity. <br />
def __init__(self, handle):<br />
...<br />
self.connect('key-press-event', self._keyPressCb)<br />
...<br />
<br />
#### Method _keyPressCb, which catches any presses of the game buttons. <br />
def _keyPressCb(self, widget, event):<br />
<br />
keyname = gtk.gdk.keyval_name(event.keyval)<br />
<br />
if (keyname == 'KP_Up'):<br />
self._chat += "\nUp Pressed!"<br />
self._chat_buffer.set_text(self._chat)<br />
elif (keyname == 'KP_Down'):<br />
self._chat += "\nDown Pressed!"<br />
self._chat_buffer.set_text(self._chat)<br />
elif (keyname == 'KP_Left'):<br />
self._chat += "\nLeft Pressed!"<br />
self._chat_buffer.set_text(self._chat)<br />
elif (keyname == 'KP_Right'):<br />
self._chat += "\nRight Pressed!"<br />
self._chat_buffer.set_text(self._chat)<br />
<br />
return False<br />
</pre><br />
<br />
=== How do i remove an specific button from the toolbar? ===<br />
<br />
This is an example of the share button is removed:<br />
<br />
<pre><br />
activity_toolbar = toolbox.get_activity_toolbar()<br />
activity_toolbar.remove(activity_toolbar.share)<br />
activity_toolbar.share = None<br />
</pre><br />
<br />
== Notes ==<br />
<references /><br />
<br />
[[Category:Documentation]]<br />
[[Category:Development Team]]</div>TuukkaHhttps://wiki.sugarlabs.org/index.php?title=Sugar_Platform_Stack&diff=39949Sugar Platform Stack2009-11-06T21:35:40Z<p>TuukkaH: add individual sections for Sugar Framework and Sugar Software Stack</p>
<hr />
<div>The [[Sugar Platform Stack]] describes the core part of the [[Sugar Application Stack]]: between an operating system and the individual activities are the Sugar Framework ("Glucose") and the Sugar Software Stack (the upper part of "Ribose").<br />
<br />
The Sugar Platform Stack is a versioned implementation of [[Development_Team/Architecture]].<br />
<br />
= Sugar Framework =<br />
<br />
The Sugar Framework ("Glucose") consists of the packages sugar-base, sugar-toolkit, sugar-datastore, sugar-presence-service, sugar-artwork and hulahop. Its latest release is as a part of the Sugar Platform release [[{{Current Stable Release}}]].<br />
<br />
= Sugar Software Stack =<br />
<br />
The Sugar Software Stack (the upper part of "Ribose") is defined by the Sugar Platform release by its external dependencies and their minimum versions - the latest one is [[0.86/Platform Components]]. This is currently roughly equivalent to GNOME Mobile.<br />
<br />
= Interfaces provided to activity developers =<br />
<br />
This section attempts to describe the major activity development stacks available in the Sugar environment.<br />
<br />
== Smalltalk/Etoys ==<br />
<br />
[[Etoys]] is a kids application written in Squeak an open-source Smalltalk development environment. Smalltalk is one of the first object-oriented languages, that is, it has been in use for decades, and as a result has a huge body of components and pre-built content and resources that can be used to create new activities.<br />
<br />
The Etoys environment is easily scripted via GUI interactions, and components have access to all of the special hardware features on the laptop. You can often create fascinating projects and useful demonstrations with just a few mouse clicks and a bit of simple logic.<br />
<br />
See: [[Smalltalk Development on XO]] to start using Squeak to develop for the OLPC.<br />
<br />
== Browser ==<br />
<br />
Sugar includes a Mozilla-Firefox-derived (Gecko) [[Web|Web Browser]] Activity. This browser includes HTML, XHTML, Javascript and SVG support. You can set up simple web-servers on a laptop using Python, or children may access an application hosted on a public web server (but keep in mind that children often have very poor connectivity).<br />
<br />
You can develop for this platform with no particular hardware or setup, and can test using regular Firefox during initial stages. It is easy to port work from elsewhere into this stack, and easy to export your work for use outside of the OLPC project. The environment is, however, rather constrained, without access to most of the special hardware or software components on the laptop.<br />
<br />
=== Browser Component ===<br />
<br />
The built-in Browser is actually just a thin wrapper around the Gecko control. You can use the Gecko control yourself and create web-browser derived activities, either using XUL or Python/PyGTK to instantiate the browser. This gives your Activity access to system services and hardware, at the cost of considerably more complexity.<br />
<br />
See: ??? to start using XULRunner/Web Control to develop for the OLPC.<br />
<br />
== Python/PyGTK ==<br />
<br />
Python and GTK based activities are the "standard" way to write software for the OLPC. Using Python and PyGTK is strongly encouraged so that the "View Source" button will normally show the same language wherever the user invokes it. The use of the same language throughout also means that code can often be factored out of one project to be shared with another.<br />
<br />
The support for writing activities provided by the core Sugar system (which is itself largely written in Python) is almost always exposed first through Python libraries. On the Sugar platform, PyGTK has access to the following major libraries:<br />
<br />
* [[Cairo]] -- high performance postscript-like library for drawing vector graphics, with the RSVG SVG-rendering library<br />
* [[Pango]] -- flexible text layout system capable of dealing with complex internationalization issues<br />
* [[D-BUS]] -- inter-process communications<br />
* Telepathy -- inter-machine RPC and presence management with network traversal and discovery logic (activities are encouraged to use Telepathy's Tubes where practical)<br />
* [http://numpy.scipy.org/ NumPy] -- standard high performance numeric analysis and array-handling module<br />
* [[CSound]] -- acoustically modelled sound-synthesis engine (seen in the [[TamTam]] activity)<br />
* [[GStreamer]] -- general purpose media streaming platform, used for accessing the video camera and playing media<br />
* [[IPython]] -- enhanced interactive Python interpreter with syntax highlighting, command-completion and the like<br />
<br />
GTK Controls:<br />
<br />
* [[Web]] Browser Control ([[HulaHop]]) -- Gecko 1.9 web browser as a simple embeddable control with Python DOM access<br />
* [[Write|AbiWord]]/AbiCollab Control -- AbiWord word processor as an embeddable control with the ability to collaboratively edit with another user<br />
** This version of AbiWord also includes support for syntax-colouring collaborative source-code editing<br />
* [[Evince]] Control -- PDF and EBook-reading control<br />
* [[#OLPCGames|Pygame]] -- game development engine based on SDL (see OLPCGames), not exactly a control, but close...<br />
<br />
in addition to the Python standard library, which includes rather a lot of built-in functionality. One key standard library module is the SQLite database engine, which provides a basic single-user SQL database which can be used by activities for storage.<br />
<br />
See: [[API Reference]] for a more exhaustive set of pointers to libraries available with links to their documentation<br />
<br />
See: [[Activity tutorial]] to develop in Python (with PyGTK) for the OLPC.<br />
<br />
Activities can use common Python extensions which are installed into their Activity directory. You may also consider rewriting areas that profiling say are problems in your activity as [[#Low Level|C extensions]]. This can save both processor load and memory depending on the nature of the extension. Keep in mind, though, that premature optimization is generally not a good idea; code first, optimize later. You can also use extensions to wrap already-existing activities (those not normally Sugar or Python based) by creating a GTK control wrapping your activity's core.<br />
<br />
See: [[#Low Level]] for a discussion of extensions lower-level programming-language issues<br />
<br />
=== OLPCGames ===<br />
<br />
[[Pygame]] is a high-level wrapper around the C [[SDL]] library, which provides low-level support for developing games. Pygame allows you to easily create raster (pixel-based) graphics for games with reasonable performance thanks to SDL.<br />
<br />
[[OLPCGames]] is a Python package which allows you to create Sugar Activities using Pygame with access to the special features of the laptop. This includes the Telepathy presence and communications infrastructure and the Pango/Cairo graphics capabilities.<br />
<br />
See: [[Game development HOWTO]] to start using Python, Pygame and OLPCGames to develop for the OLPC.<br />
<br />
See: [[Game templates]] for a set of simple templates intended to allow students to create "genres" of games easily<br />
<br />
== Flash ==<br />
<br />
Sugar includes the [[Gnash]] engine by default, and the [[Adobe Flash]] playing engine can be installed. At the moment we do not have a Flash authoring tool that can be distributed on the laptops, however. If you have Flash-based content, it may be possible to simply run it on Gnash on Sugar.<br />
<br />
== Low Level ==<br />
<br />
Being a regular Fedora 7 Linux machine, the OLPC-XO can run regular Linux i386 executables. However, integration with the Sugar shell is currently a non-trivial exercise. It is often easier to wrap your C/C++/Assembly/Whatever activity in a (normally Python) wrapper than to attempt to implement the entire [[Low-level Activity API]] yourself.<br />
<br />
See: [[Low-level Activity API]] for the most extensive and up-to-date available discussion of how to integrate a low-level activity manually<br />
<br />
See: [[Sugarizing]] for a (somewhat fragmentary) discussion of how to wrap an existing native-code executable/library with a Python wrapper.<br />
<br />
See: [http://dev.laptop.org/git?p=users/albert/sugarize;a=tree;f=xlogo.activity;hb=HEAD Sugarize Demo] for a shared library loader hack that provides much of the X11-level functionality for general X11 activities, allowing them to be run largely unchanged on the XO. Most of the special features of the laptop will not be available, but this approach allows for quick porting/testing of activities.<br />
<br />
When coding in Python, you will occasionally want access to a C or C++ extension, either one already written, or one written to optimize some part of your activity. You can build these extensions for use under Sugar by using the normal Python distutils with GCC tool chain.<br />
<br />
Make sure that you are aware (and respect) the [[Geode instruction set]]. It is about the same as the original Athlon instruction set. See the Geode data book linked in the [[Geode instruction set]] page.<br />
<br />
The best (most reliable and compatible) approach is generally to compile on an official image, using Yum to install the tools required. Doing this on an actual XO, however, is probably '''not''' a good idea, as compilation will tend to cause lots of writes to the disk and reduce the longevity of your flash storage chip.<br />
<br />
See: [[Developers/Setup#Emulation for Compilation/Experiments|Emulation for Compilation]] for a tip on how to compile using emulation</div>TuukkaHhttps://wiki.sugarlabs.org/index.php?title=Talk:Sugar_Application_Stack&diff=39948Talk:Sugar Application Stack2009-11-06T21:07:39Z<p>TuukkaH: moved Talk:Sugar Application Stack to Talk:Sugar System Stack:&#32;need to match page content</p>
<hr />
<div>#REDIRECT [[Talk:Sugar System Stack]]</div>TuukkaHhttps://wiki.sugarlabs.org/index.php?title=Talk:Sugar_System_Stack&diff=39947Talk:Sugar System Stack2009-11-06T21:07:39Z<p>TuukkaH: moved Talk:Sugar Application Stack to Talk:Sugar System Stack:&#32;need to match page content</p>
<hr />
<div>Sugar itself needs a hyperlink to drill-down into the architecture</div>TuukkaHhttps://wiki.sugarlabs.org/index.php?title=Sugar_Application_Stack&diff=39946Sugar Application Stack2009-11-06T21:07:39Z<p>TuukkaH: moved Sugar Application Stack to Sugar System Stack:&#32;need to match page content</p>
<hr />
<div>#REDIRECT [[Sugar System Stack]]</div>TuukkaHhttps://wiki.sugarlabs.org/index.php?title=Sugar_System_Stack&diff=39945Sugar System Stack2009-11-06T21:07:39Z<p>TuukkaH: moved Sugar Application Stack to Sugar System Stack:&#32;need to match page content</p>
<hr />
<div>[[Sugar]] is implemented on top of existing or modified operating systems and hardware. Sugar [[Activities]] ("Sugarized applications") are accessed by the user in the Sugar platform, integrate into a single Journal for storing, and are often designed with peer collaboration as a primary feature.<br />
<br />
== Sugar Application Stack ==<br />
<br />
{|align="right" border="1" cellpadding="3" style="border-collapse: collapse; border: solid 1px gray;"<br />
<br />
|- align="center" style="background:#ffc0c0;"<br />
|style="background:#ffc0c0;"|'''[[Human_Interface_Guidelines/The_Laptop_Experience/The_Journal|Journal]]<br>Content'''<br />
|colspan="8"|meta-tagged content datastore<br />
<br />
|- align="center" style="background:#ffffd0;"<br />
||'''Sugar<br>[[Activities]]'''<br />
|colspan="8"| Browse | Chat | Read | Write | Record | EToys | Turtle Art | Terminal | [[Activities|et al...]]<br />
|- align="center" style="background:#e0ffe0;"<br />
||'''Sugar<br>Platform'''<br />
|colspan="8"|[[Sugar Platform Stack]]: Sugar Framework and Sugar Software Stack<br />
<br />
|- align=center style="background:#e0e0ff;"<br />
||'''Operating<br>System'''<br />
|colspan="8"| [[Community/Distributions/Fedora | Fedora]] | [[Community/Distributions/Debian|Debian]] | [[Community/Distributions/Ubuntu|Ubuntu]] | [[Packaging Team|Linux, other]] | [[wikipedia:Linux_Terminal_Server_Project | LTSP]] | [[olpc:Sugar_on_MacOS_X |Mac OSX]] | [[Supported systems/Windows|MS Windows (emulation)]] | [[Packaging Team|...]]<br />
|- align=center style="background:#ffffff;"<br />
||'''Hardware<br>Platform'''<br />
||[http://en.wikipedia.org/wiki/Olpc OLPC]<br>[http://wiki.laptop.org/go/XO XO-1]<br />
||[http://en.wikipedia.org/wiki/Asus ASUS]<br>[http://en.wikipedia.org/wiki/Eee_PC EEE PC]<br />
||[http://en.wikipedia.org/wiki/Intel Intel]<br>[http://en.wikipedia.org/wiki/Classmate_PC Classmate]<br />
||[http://en.wikipedia.org/wiki/Olpc OLPC]<br>[http://wiki.laptop.org/go/XO-2 XO-2]<br />
|colspan="4"|...<br />
<br />
|}<br />
The layers in a Sugar system are:<br />
<br />
* [[Human_Interface_Guidelines/The_Laptop_Experience/The_Journal | Journal]]<br />
* [[Activities]]<br />
* [[Sugar Platform Stack]]<br />
* [[Packaging Team|Operating System]]<br />
* Computer Hardware<br />
[[Sugar Application Stack (ASCII Text)]]<br />
<br />
Sugar Labs has borrowed names from [[wikipedia:Carbohydrate | carbohydrate]] chemistry, which includes sugar, to personalize and help distinguish pieces of Sugar software. See [[Taxonomy]] and [http://www.mail-archive.com/sugar@lists.laptop.org/msg03195.html On the Naming of Sugar] for background.<br />
<br />
== Application Stack Illustration ==<br />
<br />
[[Image:Sugar Taxonomy.png|centre|450px]]<br />
[[Category:Supported systems]]</div>TuukkaHhttps://wiki.sugarlabs.org/index.php?title=Sugar_System_Stack&diff=39944Sugar System Stack2009-11-06T20:51:48Z<p>TuukkaH: remove "indoctrination", link to What is Sugar? instead</p>
<hr />
<div>[[Sugar]] is implemented on top of existing or modified operating systems and hardware. Sugar [[Activities]] ("Sugarized applications") are accessed by the user in the Sugar platform, integrate into a single Journal for storing, and are often designed with peer collaboration as a primary feature.<br />
<br />
== Sugar Application Stack ==<br />
<br />
{|align="right" border="1" cellpadding="3" style="border-collapse: collapse; border: solid 1px gray;"<br />
<br />
|- align="center" style="background:#ffc0c0;"<br />
|style="background:#ffc0c0;"|'''[[Human_Interface_Guidelines/The_Laptop_Experience/The_Journal|Journal]]<br>Content'''<br />
|colspan="8"|meta-tagged content datastore<br />
<br />
|- align="center" style="background:#ffffd0;"<br />
||'''Sugar<br>[[Activities]]'''<br />
|colspan="8"| Browse | Chat | Read | Write | Record | EToys | Turtle Art | Terminal | [[Activities|et al...]]<br />
|- align="center" style="background:#e0ffe0;"<br />
||'''Sugar<br>Platform'''<br />
|colspan="8"|[[Sugar Platform Stack]]: Sugar Framework and Sugar Software Stack<br />
<br />
|- align=center style="background:#e0e0ff;"<br />
||'''Operating<br>System'''<br />
|colspan="8"| [[Community/Distributions/Fedora | Fedora]] | [[Community/Distributions/Debian|Debian]] | [[Community/Distributions/Ubuntu|Ubuntu]] | [[Packaging Team|Linux, other]] | [[wikipedia:Linux_Terminal_Server_Project | LTSP]] | [[olpc:Sugar_on_MacOS_X |Mac OSX]] | [[Supported systems/Windows|MS Windows (emulation)]] | [[Packaging Team|...]]<br />
|- align=center style="background:#ffffff;"<br />
||'''Hardware<br>Platform'''<br />
||[http://en.wikipedia.org/wiki/Olpc OLPC]<br>[http://wiki.laptop.org/go/XO XO-1]<br />
||[http://en.wikipedia.org/wiki/Asus ASUS]<br>[http://en.wikipedia.org/wiki/Eee_PC EEE PC]<br />
||[http://en.wikipedia.org/wiki/Intel Intel]<br>[http://en.wikipedia.org/wiki/Classmate_PC Classmate]<br />
||[http://en.wikipedia.org/wiki/Olpc OLPC]<br>[http://wiki.laptop.org/go/XO-2 XO-2]<br />
|colspan="4"|...<br />
<br />
|}<br />
The layers in a Sugar system are:<br />
<br />
* [[Human_Interface_Guidelines/The_Laptop_Experience/The_Journal | Journal]]<br />
* [[Activities]]<br />
* [[Sugar Platform Stack]]<br />
* [[Packaging Team|Operating System]]<br />
* Computer Hardware<br />
[[Sugar Application Stack (ASCII Text)]]<br />
<br />
Sugar Labs has borrowed names from [[wikipedia:Carbohydrate | carbohydrate]] chemistry, which includes sugar, to personalize and help distinguish pieces of Sugar software. See [[Taxonomy]] and [http://www.mail-archive.com/sugar@lists.laptop.org/msg03195.html On the Naming of Sugar] for background.<br />
<br />
== Application Stack Illustration ==<br />
<br />
[[Image:Sugar Taxonomy.png|centre|450px]]<br />
[[Category:Supported systems]]</div>TuukkaHhttps://wiki.sugarlabs.org/index.php?title=Sugar_System_Stack&diff=39943Sugar System Stack2009-11-06T20:37:21Z<p>TuukkaH: /* Sugar Application Stack */ replace Sugar by Sugar Platform Stack</p>
<hr />
<div><noinclude><br />
<noinclude><br />
Sugar is designed to encourage exploration and learning by children that have not been exposed to<br />
or indoctrinated into any existing computing environment. <br />
</noinclude><br />
===The Sugar Stack===<br />
Sugar is implemented on top of existing or modified operating systems and hardware. Sugar Activities ("Sugarized applications") are accessed by the user in the Sugar platform, integrate into a single Journal for storing, and are often designed with peer collaboration as a primary feature.<br />
<br />
== Sugar Application Stack ==<br />
<br />
{|align="right" border="1" cellpadding="3" style="border-collapse: collapse; border: solid 1px gray;"<br />
<br />
|- align="center" style="background:#ffc0c0;"<br />
|style="background:#ffc0c0;"|'''[[Human_Interface_Guidelines/The_Laptop_Experience/The_Journal|Journal]]<br>Content'''<br />
|colspan="8"|meta-tagged content datastore<br />
<br />
|- align="center" style="background:#ffffd0;"<br />
||'''Sugar<br>[[Activities]]'''<br />
|colspan="8"| Browse | Chat | Read | Write | Record | EToys | Turtle Art | Terminal | [[Activities|et al...]]<br />
|- align="center" style="background:#e0ffe0;"<br />
||'''Sugar<br>Platform'''<br />
|colspan="8"|[[Sugar Platform Stack]]: Sugar Framework and Sugar Software Stack<br />
<br />
|- align=center style="background:#e0e0ff;"<br />
||'''Operating<br>System'''<br />
|colspan="8"| [[Community/Distributions/Fedora | Fedora]] | [[Community/Distributions/Debian|Debian]] | [[Community/Distributions/Ubuntu|Ubuntu]] | [[Packaging Team|Linux, other]] | [[wikipedia:Linux_Terminal_Server_Project | LTSP]] | [[olpc:Sugar_on_MacOS_X |Mac OSX]] | [[Supported systems/Windows|MS Windows (emulation)]] | [[Packaging Team|...]]<br />
|- align=center style="background:#ffffff;"<br />
||'''Hardware<br>Platform'''<br />
||[http://en.wikipedia.org/wiki/Olpc OLPC]<br>[http://wiki.laptop.org/go/XO XO-1]<br />
||[http://en.wikipedia.org/wiki/Asus ASUS]<br>[http://en.wikipedia.org/wiki/Eee_PC EEE PC]<br />
||[http://en.wikipedia.org/wiki/Intel Intel]<br>[http://en.wikipedia.org/wiki/Classmate_PC Classmate]<br />
||[http://en.wikipedia.org/wiki/Olpc OLPC]<br>[http://wiki.laptop.org/go/XO-2 XO-2]<br />
|colspan="4"|...<br />
<br />
|}<br />
The layers in a Sugar system are:<br />
<br />
* [[Human_Interface_Guidelines/The_Laptop_Experience/The_Journal | Journal]]<br />
* [[Activities]]<br />
* [[Sugar Platform Stack]]<br />
* [[Packaging Team|Operating System]]<br />
* Computer Hardware<br />
[[Sugar Application Stack (ASCII Text)]]<br />
<br />
Sugar Labs has borrowed names from [[wikipedia:Carbohydrate | carbohydrate]] chemistry, which includes sugar, to personalize and help distinguish pieces of Sugar software. See [[Taxonomy]] and [http://www.mail-archive.com/sugar@lists.laptop.org/msg03195.html On the Naming of Sugar] for background.<br />
<br />
== Application Stack Illustration ==<br />
<br />
[[Image:Sugar Taxonomy.png|centre|450px]]<br />
[[Category:Supported systems]]</div>TuukkaHhttps://wiki.sugarlabs.org/index.php?title=0.86/Platform_Components&diff=399420.86/Platform Components2009-11-06T20:28:35Z<p>TuukkaH: link to Sugar Platform Stack</p>
<hr />
<div><noinclude>{{GoogleTrans-en}}</noinclude>[[Category:Platform Cycle]]<br />
The [[Sugar Platform Stack]] is a set of versioned components on which activity authors can rely when targeting their activities to run on a particular Sugar version.<br />
<br />
Activity authors can expect to find the following components in a system running Sugar 0.86:<br />
<br />
{| border=1 cellpadding=3 style="border: 1px solid white; border-collapse: collapse; background: #e3e4e5;"<br />
|-style="background:#787878; color: white;"<br />
! Name<br />
! Version<br />
! [http://api.sugarlabs.org <font color="#ffffff">API</font>] docs<br />
! Notes<br />
|-<br />
|Python<br />
|2.5/2.6<br />
|<br />
|<br />
|-<br />
| [http://www.gtk.org/ Gtk+]<br />
| 2.16<br />
| http://www.gtk.org/documentation.html<br />
| Should we split this in glib, gobject, gio, etc?<br />
|-<br />
| [http://www.gstreamer.net/ GStreamer]<br />
| 0.10<br />
| http://gstreamer.freedesktop.org/data/doc/gstreamer/head/gstreamer-libs/html/<br />
| <br />
|-<br />
| [http://telepathy.freedesktop.org/wiki Telepathy]<br />
| 0.7.25<br />
| http://telepathy.freedesktop.org/wiki/Telepathy%20GLib<br />
| <br />
|-<br />
| [http://projects.gnome.org/evince Evince]<br />
| 2.26<br />
| http://library.gnome.org/devel/libevview/unstable http://library.gnome.org/devel/libevdocument/unstable/<br />
| Should we split this in libevview and libevdocument?<br />
|-<br />
| [http://www.abisource.com Abiword]<br />
| 2.6<br />
| <br />
| <br />
|-<br />
| [http://www.squeakland.org Etoys]<br />
| 4.0.2206<br />
| <br />
| <br />
|-<br />
| PyGObject<br />
| 2.16<br />
| http://www.pygtk.org/docs/pygobject/index.html<br />
| API link outdated<br />
|-<br />
| PyGTK<br />
| 2.14<br />
| http://www.pygtk.org/docs/pygtk/index.html<br />
| API link outdated<br />
|-<br />
| dbus<br />
| 1.1x<br />
|<br />
|<br />
|-<br />
| [http://squeakvm.org/unix/ squeak]<br />
| 3.10-4<br />
| <br />
|<br />
|-<br />
|gstreamer<br />
|0.10.14<br />
|<br />
|<br />
|-<br />
|gst-plugins-base<br />
|0.10.15<br />
|<br />
|<br />
|-<br />
|gst-plugins-good<br />
|0.10.6<br />
|<br />
|<br />
|-<br />
|gst-plugins-espeak<br />
|0.3<br />
|<br />
|<br />
|-<br />
|espeak<br />
|1.40.02<br />
|<br />
|<br />
|-<br />
|numpy<br />
|1.0.3<br />
|<br />
|<br />
|-<br />
|pygame<br />
|1.7.1<br />
|<br />
|<br />
|-<br />
|olpcsound / csound / csound-python<br />
|5.08/5.10<br />
|<br />
|<br />
|-<br />
|libxml2-python<br />
|2.6.30<br />
|<br />
|<br />
|<br />
|-<br />
|libffi<br />
|3.0.5<br />
|<br />
|<br />
|<br />
|}<br />
<br />
{{Template:Developers}}<br />
* [http://library.gnome.org/devel/platform-overview/nightly GNOME platform]<br />
<br />
[[Category:Development Team]]</div>TuukkaHhttps://wiki.sugarlabs.org/index.php?title=Sugar_Platform_Stack&diff=39941Sugar Platform Stack2009-11-06T20:09:06Z<p>TuukkaH: copy http://wiki.laptop.org/go/Developers/Stack#Activity_Development_Stacks</p>
<hr />
<div>The [[Sugar Platform Stack]] describes the core part of the [[Sugar Application Stack]]: between an operating system and the individual activities are the Sugar Framework (known as Glucose) and the Sugar Software Stack (the upper part of Ribose - roughly GNOME Mobile. See [[0.86/Platform_Components]].).<br />
<br />
The Sugar Platform Stack is a versioned implementation of [[Development_Team/Architecture]].<br />
<br />
= Interfaces provided to activity developers =<br />
<br />
This section attempts to describe the major activity development stacks available in the Sugar environment.<br />
<br />
== Smalltalk/Etoys ==<br />
<br />
[[Etoys]] is a kids application written in Squeak an open-source Smalltalk development environment. Smalltalk is one of the first object-oriented languages, that is, it has been in use for decades, and as a result has a huge body of components and pre-built content and resources that can be used to create new activities.<br />
<br />
The Etoys environment is easily scripted via GUI interactions, and components have access to all of the special hardware features on the laptop. You can often create fascinating projects and useful demonstrations with just a few mouse clicks and a bit of simple logic.<br />
<br />
See: [[Smalltalk Development on XO]] to start using Squeak to develop for the OLPC.<br />
<br />
== Browser ==<br />
<br />
Sugar includes a Mozilla-Firefox-derived (Gecko) [[Web|Web Browser]] Activity. This browser includes HTML, XHTML, Javascript and SVG support. You can set up simple web-servers on a laptop using Python, or children may access an application hosted on a public web server (but keep in mind that children often have very poor connectivity).<br />
<br />
You can develop for this platform with no particular hardware or setup, and can test using regular Firefox during initial stages. It is easy to port work from elsewhere into this stack, and easy to export your work for use outside of the OLPC project. The environment is, however, rather constrained, without access to most of the special hardware or software components on the laptop.<br />
<br />
=== Browser Component ===<br />
<br />
The built-in Browser is actually just a thin wrapper around the Gecko control. You can use the Gecko control yourself and create web-browser derived activities, either using XUL or Python/PyGTK to instantiate the browser. This gives your Activity access to system services and hardware, at the cost of considerably more complexity.<br />
<br />
See: ??? to start using XULRunner/Web Control to develop for the OLPC.<br />
<br />
== Python/PyGTK ==<br />
<br />
Python and GTK based activities are the "standard" way to write software for the OLPC. Using Python and PyGTK is strongly encouraged so that the "View Source" button will normally show the same language wherever the user invokes it. The use of the same language throughout also means that code can often be factored out of one project to be shared with another.<br />
<br />
The support for writing activities provided by the core Sugar system (which is itself largely written in Python) is almost always exposed first through Python libraries. On the Sugar platform, PyGTK has access to the following major libraries:<br />
<br />
* [[Cairo]] -- high performance postscript-like library for drawing vector graphics, with the RSVG SVG-rendering library<br />
* [[Pango]] -- flexible text layout system capable of dealing with complex internationalization issues<br />
* [[D-BUS]] -- inter-process communications<br />
* Telepathy -- inter-machine RPC and presence management with network traversal and discovery logic (activities are encouraged to use Telepathy's Tubes where practical)<br />
* [http://numpy.scipy.org/ NumPy] -- standard high performance numeric analysis and array-handling module<br />
* [[CSound]] -- acoustically modelled sound-synthesis engine (seen in the [[TamTam]] activity)<br />
* [[GStreamer]] -- general purpose media streaming platform, used for accessing the video camera and playing media<br />
* [[IPython]] -- enhanced interactive Python interpreter with syntax highlighting, command-completion and the like<br />
<br />
GTK Controls:<br />
<br />
* [[Web]] Browser Control ([[HulaHop]]) -- Gecko 1.9 web browser as a simple embeddable control with Python DOM access<br />
* [[Write|AbiWord]]/AbiCollab Control -- AbiWord word processor as an embeddable control with the ability to collaboratively edit with another user<br />
** This version of AbiWord also includes support for syntax-colouring collaborative source-code editing<br />
* [[Evince]] Control -- PDF and EBook-reading control<br />
* [[#OLPCGames|Pygame]] -- game development engine based on SDL (see OLPCGames), not exactly a control, but close...<br />
<br />
in addition to the Python standard library, which includes rather a lot of built-in functionality. One key standard library module is the SQLite database engine, which provides a basic single-user SQL database which can be used by activities for storage.<br />
<br />
See: [[API Reference]] for a more exhaustive set of pointers to libraries available with links to their documentation<br />
<br />
See: [[Activity tutorial]] to develop in Python (with PyGTK) for the OLPC.<br />
<br />
Activities can use common Python extensions which are installed into their Activity directory. You may also consider rewriting areas that profiling say are problems in your activity as [[#Low Level|C extensions]]. This can save both processor load and memory depending on the nature of the extension. Keep in mind, though, that premature optimization is generally not a good idea; code first, optimize later. You can also use extensions to wrap already-existing activities (those not normally Sugar or Python based) by creating a GTK control wrapping your activity's core.<br />
<br />
See: [[#Low Level]] for a discussion of extensions lower-level programming-language issues<br />
<br />
=== OLPCGames ===<br />
<br />
[[Pygame]] is a high-level wrapper around the C [[SDL]] library, which provides low-level support for developing games. Pygame allows you to easily create raster (pixel-based) graphics for games with reasonable performance thanks to SDL.<br />
<br />
[[OLPCGames]] is a Python package which allows you to create Sugar Activities using Pygame with access to the special features of the laptop. This includes the Telepathy presence and communications infrastructure and the Pango/Cairo graphics capabilities.<br />
<br />
See: [[Game development HOWTO]] to start using Python, Pygame and OLPCGames to develop for the OLPC.<br />
<br />
See: [[Game templates]] for a set of simple templates intended to allow students to create "genres" of games easily<br />
<br />
== Flash ==<br />
<br />
Sugar includes the [[Gnash]] engine by default, and the [[Adobe Flash]] playing engine can be installed. At the moment we do not have a Flash authoring tool that can be distributed on the laptops, however. If you have Flash-based content, it may be possible to simply run it on Gnash on Sugar.<br />
<br />
== Low Level ==<br />
<br />
Being a regular Fedora 7 Linux machine, the OLPC-XO can run regular Linux i386 executables. However, integration with the Sugar shell is currently a non-trivial exercise. It is often easier to wrap your C/C++/Assembly/Whatever activity in a (normally Python) wrapper than to attempt to implement the entire [[Low-level Activity API]] yourself.<br />
<br />
See: [[Low-level Activity API]] for the most extensive and up-to-date available discussion of how to integrate a low-level activity manually<br />
<br />
See: [[Sugarizing]] for a (somewhat fragmentary) discussion of how to wrap an existing native-code executable/library with a Python wrapper.<br />
<br />
See: [http://dev.laptop.org/git?p=users/albert/sugarize;a=tree;f=xlogo.activity;hb=HEAD Sugarize Demo] for a shared library loader hack that provides much of the X11-level functionality for general X11 activities, allowing them to be run largely unchanged on the XO. Most of the special features of the laptop will not be available, but this approach allows for quick porting/testing of activities.<br />
<br />
When coding in Python, you will occasionally want access to a C or C++ extension, either one already written, or one written to optimize some part of your activity. You can build these extensions for use under Sugar by using the normal Python distutils with GCC tool chain.<br />
<br />
Make sure that you are aware (and respect) the [[Geode instruction set]]. It is about the same as the original Athlon instruction set. See the Geode data book linked in the [[Geode instruction set]] page.<br />
<br />
The best (most reliable and compatible) approach is generally to compile on an official image, using Yum to install the tools required. Doing this on an actual XO, however, is probably '''not''' a good idea, as compilation will tend to cause lots of writes to the disk and reduce the longevity of your flash storage chip.<br />
<br />
See: [[Developers/Setup#Emulation for Compilation/Experiments|Emulation for Compilation]] for a tip on how to compile using emulation</div>TuukkaHhttps://wiki.sugarlabs.org/index.php?title=Sugar_Platform_Stack&diff=39940Sugar Platform Stack2009-11-06T20:06:17Z<p>TuukkaH: initial version, incomplete</p>
<hr />
<div>The [[Sugar Platform Stack]] describes the core part of the [[Sugar Application Stack]]: between an operating system and the individual activities are the Sugar Framework (known as Glucose) and the Sugar Software Stack (the upper part of Ribose - roughly GNOME Mobile. See [[0.86/Platform_Components]].).<br />
<br />
The Sugar Platform Stack is a versioned implementation of [[Development_Team/Architecture]].<br />
<br />
= Interfaces provided to activity developers =<br />
<br />
This section attempts to describe the major Activity development stacks available in the OLPC Sugar environment.</div>TuukkaHhttps://wiki.sugarlabs.org/index.php?title=Ideas_for_Projects&diff=39934Ideas for Projects2009-11-06T16:35:55Z<p>TuukkaH: copyedit</p>
<hr />
<div><noinclude>{{GoogleTrans-en}}</noinclude>{{TOCright}}<br />
<br />
This list was brainstormed as ideas for High School student groups, however, its totally appropriate for everyone from teens to grannies. Use this as a starting point and follow your own interests and skills.<br />
<br />
===Documentation===<br />
* Create instructions, tutorials or videos for the hundreds of activities for Sugar that currently lack them.<br />
* Translate existing documentation.<br />
* Scavenger hunt for what documentation and information there is about an activity and how its used and bring all that information together. This is especially good for Spanish speakers/learners as much of the usage is in South America.<br />
<br />
===Language===<br />
* Translate documentation and activities to your own language, perhaps with the help of others such as parents with better language skills.<br />
* Translate an interesting post from the Spanish speaking list and post it on the English speaking list, or vice versa.<br />
<br />
===Get Sugar on a Stick to work on your computers===<br />
* Document what you did and any problems.<br />
* Document what your computer is: chipsets, specs, etc.<br />
* Test performance on different types of equipment and help us find out what are the limiting factors.<br />
<br />
===Take Sugar on a Stick to your old elementary school===<br />
* Do a lesson in the computer lab.<br />
* Work with a teacher and create a lesson aligned with the curriculum. Post the lesson plan, how it went and what curriculum standards it aligns to - Just imagine if we could get thousands of high school students doing a dozen of these each!<br />
* Make a documentary of kids using Sugar.<br />
<br />
===Programming===<br />
''To sugarize'' means taking a program like Tux Paint or GCompris and making it use Sugar's special features of saving automatically to the Journal, sharing and collaboration. Many programs need sugarizing:<br />
<br />
* All the different GCompris pieces<br />
* TuxPaint<br />
* Scratch<br />
* Many others that I don't know off the top of my head<br />
<br />
Moodle Integration - Sugar already has single sign-on but there is so much more to do:<br />
<br />
* Launching a Sugar activity from Moodle<br />
* Letting a teacher create a Moodle activity that launches an activity in Sugar and then automatically saves to the Moodle drop box<br />
* What-you-Paint-is-What-you-Get (wypiwig) plug-in for Moodle<br />
<br />
School server:<br />
* Set up an XS and document what you did.<br />
* Test scalability of XS and Jabber.<br />
<br />
[[Category:Idea]]</div>TuukkaHhttps://wiki.sugarlabs.org/index.php?title=Webified&diff=39924Webified2009-11-05T18:40:04Z<p>TuukkaH: add links to current activity at the top</p>
<hr />
<div>{{TOCright}}<br />
''The results of this project are now in the [[Activities/Browse|Browse]] activity and at [http://git.sugarlabs.org/projects/browse/repos/webified a branch of Browse]. See also complementary work on [[Karma]].''<br />
====About you====<br />
<br />
* '''What is your name?'''<br />
Lucian Branescu Mihaila<br />
* '''What is your email address?'''<br />
lucian dot braneNOSPAMscu at gmail dot com<br />
* '''What is your Sugar Labs wiki username?'''<br />
lucian<br />
* '''What is your IRC nickname?'''<br />
lucian. backups are lucian1900 and sindbad1900<br />
* '''What is your primary language? (We have mentors who speak multiple languages and can match you with one of them if you'd prefer.)'''<br />
English and Romanian, either is fine.<br />
* '''Where are you located, and what hours do you tend to work? (We also try to match mentors by general time zone if possible.)'''<br />
Mostly in the UK, perhaps a short while in Romania during the summer break.<br /> I don't have a 'coding time' in my schedule, anything goes. I also often stay up late at night.<br />
* '''Have you participated in an open-source project before? If so, please send us URLs to your profile pages for those projects, or some other demonstration of the work that you have done in open-source. If not, why do you want to work on an open-source project this summer?'''<br />
I've started a small project on freshmeat called statusPidgin that fetched text from various sources and made it a status message in Pidgin. It's now abandoned, but you can find the source [http://linux.softpedia.com/get/Communications/Chat/statusPidgin-31896.shtml on softpedia ]<br /><br />
I have also released one of my school projects as open source (a small web imap/pop3 client), but I doubt it's still hosted anywhere since there was little interest. You can get it from [http://dl.getdropbox.com/u/317039/easymail.zip my dropbox]. I haven't contributed in a significant way to open source projects before, beside bug reports and small patches. <br /><br />
I am a user of open source (linux, KDE, gcc, python, firefox, webkit) and am absolutely delighted by the concept. I am convinced it is the most efficient way of developing software, and perhaps not only software.<br /><br />
I am especially interested in the Sugar project, as I have myself experienced the closed-mindedness that schools instill in their students by teaching them using closed source software. I have been fortunate enough to get some exposure to linux and kde early enough and I would like to help others by showing them the alternatives.<br />
<br />
====About your project====<br />
<br />
* '''What is the name of your project?'''<br />
Webified<br />
* '''Describe your project in 10-20 sentences. What are you making? Who are you making it for, and why do they need it? What technologies (programming languages, etc.) will you be using?'''<br />
I'm making a template [http://en.wikipedia.org/wiki/Site-specific_browser SSB] activity and a small utility that can create activities out of websites using that template. This combination will make sugarizing web apps almost entirely automatic.<br/><br/><br />
<br />
The purpose of this project is twofold:<br /><br />
* it would make it easy to "sugarize" web apps (like gmail).<br /><br />
Users could press a button in the Browse activity (or there could be a separate activity for this) and a small tool would help them create a sugarized web app as a new activity.<br />
* there are a lots of web developers out there that are familiar with HTML(5), CSS and JavaScript and it would be great to take advantage of their skills.<br /><br />
Web developers could use Webified to port their web apps to sugar using only web technologies, without having to learn Python.<br /><br /><br />
I have been inspired by [http://fluidapp.com/ Fluid], which creates custom SSBs for websites. Fluid has Gears and GreaseMonkey plugins and provides a simple JavaScript API to websites for common native calls (like sounds, notifications, badges, etc.), which makes it very easy to extend web apps to provide more integration. For example, GMail in a custom Fluid SSB feels like a native application.<br />
<br /><br /><br />
There are two main strategies for implementing this:<br />
# Running a standard browser, as light as possible, that points to a small local webserver (SimpleHTTPServer). It would use AJAX or a wrapper on top of that (like jsonrpc) to provide the bridge to python. The biggest downside would be that the SSB would have to call the python backend for persistence and interaction with Sugar. Another problem would be that this process could not easily be automated. Some python code would have to be written for any semi-interesting application. It would also be harder for web developers to hack Webified itself.<br />
# In a small controller application, embed a browser runtime (with hulahop). The resulting activity would be completely standalone and would not depend on a web server anymore. Gears would have to be installed as a plugin for xulrunner. Some form of [https://addons.mozilla.org/en-US/firefox/addon/748 GreaseMonkey] would be very useful. Javascript dbus access through [http://sandbox.movial.com/wiki/index.php/Browser_DBus_Bridge#WebKit_.28JavaScriptCore.29_version_notes this bridge], [https://www.socialtext.net/lukec/index.cgi?xocom XOCOM], pyxpcom directly or, in a worst case scenario, AJAX. It would be very similar to other efforts to bring web apps to the desktop and it could also provide better integration with Sugar.<br />Browse could be used as a base for the Webified SSB. A small utility (probably an extension to the Browse activity) would create activities (XO bundles) out of websites.<br /><br />
I will be focusing on the second stragety.<br /><br />
<br />
* Why not use existing solutions like Mozilla Prism or Titanium?<br />
# Prism. It's just a stripped-down firefox. To make it useful, at least Gears would have to be installed and there would still remain the issue of integration, since Prism is designed for regular desktops. Building on hulahop and the existing Browse activity would yield better integration. There may still be useful code in Prism, like the SSB creation utility. <br />
# Titanium. Titanium is more interesting, as it already is an SDK for creating desktop applications with web technologies. It's only real technical disadvantage is introducing a new dependency (webkit) in Sugar. However, it's [http://titanium-js.appspot.com/Core/Titanium design] is largely incompatible with Sugar, as it focuses on traditional desktops. Refactoring all that to fit into Sugar would be too much work.<br /><br />
<br />
* '''What is the timeline for development of your project? The Summer of Code work period is 7 weeks long, May 23 - August 10; tell us what you will be working on each week. (As the summer goes on, you and your mentor will adjust your schedule, but it's good to have a plan at the beginning so you have an idea of where you're headed.) Note that you should probably plan to have something "working and 90% done" by the midterm evaluation (July 6-13); the last steps always take longer than you think, and we will consider cancelling projects which are not mostly working by then.'''<br />
<br />
<br />'''Milestones'''<br />
Legend: - todo, + prototype done, # done<br />
* Webified SSB can load a website (hello world)<br />
: Requires: <br />
:: # getting more familiar with Sugar and Browse code<br />
:: # building the Webified SSB.<br />
: '''Week 1'''<br />
* Both Browse and Webified SSB can use GMail in offline mode (through Gears)<br />
: Requires: <br />
:: + getting the Firefox Gears extension working in Browse and the Webified SSB<br />
: '''Week 2, at worst 3'''<br />
* Browse (with its utility extension) can successfully "sugarize" GMail and the resulting activity works.<br />
: Requires:<br />
:: # activity template as host for the Webified SSB<br />
::: '''Week 3'''<br />
:: # python tool that packages up activities, using the activity template<br />
::: '''Week 3, at worst 4'''<br />
:: # button in Browse that uses the python tool<br />
::: '''Week 4'''<br />
* JavaScript from inside a Webified SSB can call dbus stuff<br />
: Dbus is vital for good integration, but there may not be enough time in GSoC for making a nice JavaScript-side API. So I will at least provide a javascript-dbus bridge that web developers can build on.<br />
: Requires investigating:<br />
:: + [http://sandbox.movial.com/wiki/index.php/Browser_DBus_Bridge#Gecko_version_notes This] javascript-dbus bridge<br />
:: - if that is not appropriate, try marshalling calls to Python with [http://en.wikipedia.org/wiki/JSON-RPC JSON-RPC]<br />
::: - through PyXPCOM (hulahop). almost as good as a direct bridge<br />
::: - through AJAX. sounds like the easiest way, but doing some [http://en.wikipedia.org/wiki/Cross-site_scripting XSS] would be needed<br />
: '''Week 5'''<br />
<br />
The remaining time could then be spent on polishing things up and for any eventual emergencies.<br />
<br />
If I have extra time. In no particular order.<br />
* Webified SSB can save and restore its state with the Journal.<br />
: Save & restore the browser state. possibilities:<br />
:: # Browse does this<br />
: Save & restore Gears state<br />
:: # do nothing. Gears provides resuming state. The only real drawback is that only the latest version will be available to resume. No actual data would be stored in the Journal.<br />
:: - save the entire Gears profile. Could be very slow for large profiles.<br />
:: - save just the sqlite databases. Could be very slow for large databases (GMail).<br />
* Build a JavaScript-side API for basic functionality that cannot be achieved easily with HTML and Gears<br />
: - similar in concept to [http://fluidapp.com/developer/ Fluid's], but tailored for Sugar. Based on the javascript-dbus bridge<br />
* Webified SSB can run a userscript (GreaseMonkey)<br />
: + should be as easy as injecting some JavaScript in the page<br />
: - a GUI like the one GreaseMonkey has is outside the scope of this project<br />
: - there will be instructions for how to add/remove userscripts<br />
* Webified SSB can use a userstyle (CSS)<br />
: # a user stylesheet can be made in data/style.user.css<br />
: + there's a GUI for it<br />
<br />
Beyond GSoC, I would like to keep working on this.<br />
<br />
<br />
* '''Convince us, in 5-15 sentences, that you will be able to successfully complete your project in the timeline you have described. This is usually where people describe their past experiences, credentials, prior projects, schoolwork, and that sort of thing, but be creative. Link to prior work or other resources as relevant.'''<br />
<br />
Python is my favourite programming language and JavaScript is a close enough second.<br />
I have some experience with python and I've built various things, from small utilities to websites with it. My most interesting project was helping to port a scientific application from c++ and Qt3 to Python and Qt4. It involved writing some Pyrex as well. It was lovely to see just how much the code shrunk, while keeping the application itself just as speedy.<br />
<br />
I have used JavaScript and HTML to build a small web game, Mousebuster (not online, get it from [http://dl.getdropbox.com/u/317039/mousebuster.zip my dropbox]). Although at first I did not like javascript at all, I quickly realised it's immense advantage: huge existing install base.<br />
<br />
I also had some contact with C# and Java and have been thoroughly disappointed by their general lack of expressiveness. I did one small schoolwork in C#, that dealt with a [http://dl.getdropbox.com/u/317039/csharp.zip database of students]. Recently, I did another small schoolwork in Java, dealing with a [http://dl.getdropbox.com/u/317039/cricket.zip cricket club]. After finishing each, I was amazed at how much of my code was just boilerplate or fighting the type system, code that I wouldn't have had to write in a more dynamic language.<br />
<br />
I also used various linux distros for several years, until last year. I got a macbook as a gift and broadcom drivers are still a mess, but that'll get fixed at some point. I found unix in general so intriguing that I set up a small home server with a 300mhz CPU. I put debian on it and used it for various purposes, from web hosting, file serving, distcc node to a router for my home.<br />
<br />
Since I was using a lot of open source at home, I tried to push it in school as well. I managed to make students and teachers aware of GCC as a replacement for Borland C/C++, Mono and SharpDevelop as a replacement for the not-quite-free Visual Studio. With the help of a friend, I even managed to convince the head of school to install Ubuntu in one of the labs.<br />
<br />
====You and the community====<br />
* '''If your project is successfully completed, what will its impact be on the Sugar Labs community? Give 3 answers, each 1-3 paragraphs in length. The first one should be yours. The other two should be answers from members of the Sugar Labs community, at least one of whom should be a Sugar Labs GSoC mentor. Provide email contact information for non-GSoC mentors.'''<br />
'''Myself''' <br /><br />
:The result of my project would be something akin to Fluid (and Prism), but tailored for Sugar. It would allow users to make separate activities out of websites and, if those websites support Gears, also take them offline.<br /><br />
:The web is moving towards websites-as-applications and there are many projects to help integrate these new applications with the various desktop environments ([http://en.wikipedia.org/wiki/Adobe_Integrated_Runtime AIR], [http://en.wikipedia.org/wiki/Silverlight#Silverlight_3 Silverlight Out-of-Browser Experience], [http://developer.mozilla.org/en/Prism Mozilla Prism], [http://fluidapp.com Fluid]). There is also the bold [http://en.wikipedia.org/wiki/Palm_webOS webOS] from Palm, that fully embraces web technologies by making them the default toolkit for building applications for the platform.<br />
:It would be great to bring these ideas to Sugar, as they would enable easier usage of web applications and in general more orientation towards the web. It would also allow web developers to easily extend those websites to better integrate with Sugar, increasing the developer pool of and raising awareness towards Sugar.<br /><br />
'''Bryan Berry''' [http://lists.sugarlabs.org/archive/iaep/2009-January/003451.html mailing list thread]<br /><br />
:Again, this requires people to learn python, a whole new language that they don't necessarily use at work. We need to enable developers to be very productive in just 2-3 hours per week. For them to be productive they need to be using tools they are already familiar w/.<br />
:Python is a tool popular among sysadmins and hackers. It is great tool. But folks who develop web UIs use css, html, javascript, and flash. I highly doubt that will change in the near or distant future. These are people we need to recruit as activity designers.<br />
'''Tomeu Vizoso''' [http://lists.sugarlabs.org/archive/iaep/2009-January/003445.html same mailing list thread] <br /><br />
: Without needing to get into what is better for our deployments, I do see value in making easier to make Sugar activities using technologies such as HTML, CSS, etc.<br />
* '''Sugar Labs will be working to set up a small (5-30 unit) Sugar pilot near each student project that is accepted to GSoC so that you can immediately see how your work affects children in a deployment. We will make arrangements to either supply or find all the equipment needed. Do you have any ideas on where you would like your deployment to be, who you would like to be involved, and how we can help you and the community in your area begin it?'''<br />
I'm not familiar with schools near where I live, as I am an international student. [Any suggestions?]<br />
* '''What will you do if you get stuck on your project and your mentor isn't around?'''<br />
Google, check sugarlabs/olpc forums/mailing lists/wikis. Ask on #sugar/mailing list.<br />
Ask other mentors and GSoC students or developers of related open source software.<br />
* '''How do you propose you will be keeping the community informed of your progress and any problems or questions you might have over the course of the project?'''<br />
In the worst case scenario, just emails to my mentor and commits. IRC has proven itself time and again and I intend to proudly announce any advances made.<br />
I intend to set up a blog and use that as well. Identi.ca or Twitter may also prove useful.<br />
<br />
====Miscellaneous====<br />
[[Image:lucian-dev-env.png|thumb|right|My development environment with the small hack.]]<br />
* '''We want to make sure that you can set up a [[Development Team#Development_systems|development environment]] before the summer starts. Please send us a link to a screenshot of your Sugar development environment with the following modification: when you hover over the XO-person icon in the middle of Home view, the drop-down text should have your email in place of "Restart." See the image on the right for an example. It's normal to need assistance with this, so please visit our IRC channel, #sugar on irc.freenode.net, and ask for help.'''<br />
Picture to the right.<br />
* '''What is your t-shirt size? (Yes, we know Google asks for this already; humor us.)'''<br />
XL<br />
* '''Describe a great learning experience you had as a child.'''<br />
The most important thing I ever learned was to never be certain of anything and to always be prepared for the worst.<br />
* '''Is there anything else we should have asked you or anything else that we should know that might make us like you or your project more?'''<br />
Web technologies are remarkably flexible and it would be great to encourage students to play around with them.<br />
<br />
[[Category:2009 GSoC applications]]</div>TuukkaH