Getting started programming: Difference between revisions
Jump to navigation
Jump to search
(→Option 1 - Emulated XO: Clarify when recommended) |
(Redirecting to Developers manual) |
||
(One intermediate revision by one other user not shown) | |||
Line 1: | Line 1: | ||
#REDIRECT [[Developers manual]] |
|||
{{Translations}} |
{{Translations}} |
||
Thank you for considering working on the One Laptop Per Child project. This page tries to provide you with the answers you need to get started either by contributing to existing projects or starting your own. Getting started is not yet as easy as we would like it to be ([[OLPC growing pains]]) - helping with that is one of many ways you might contribute. |
|||
<div> |
|||
__TOC__ |
|||
</div> |
|||
== Where to find code == |
|||
On our trac install, mostly - http://dev.laptop.org. |
|||
Check out [[Development terminology]] for a description of some of the labels we use there. |
|||
=== Current release schedule === |
|||
<pre> |
|||
2006-11-18 Factory.1 (Build 185; Firmware Q2B11) |
|||
2007-04-31 Factory.2 (Build 386; Firmware Q2C09) |
|||
2007-05-08 Factory.3 (Build 406; Firmware Q2C11) |
|||
2007-08-04 Factory.4 (Build 542; Firmware Q2C22) |
|||
2007-10-26 Factory.5 (Build 622; Firmware Q2D02) |
|||
2007-10-30 Ship.1 (Build 623; Firmware Q2D03) |
|||
2007-11-02 Feature freeze for Update.1 |
|||
2007-12-01 Update.1 (==Ship.2) |
|||
</pre> |
|||
We expect to be doing updates monthly through the first quarter of 2008. After that, we will likely adopt a three-month update cycle. Eventually we will adopt a six-month update cycle. |
|||
It should also be noted that we will be—when time permits—moving to a build environment that enables individual activity developers to maintain their own build cycles. |
|||
== Setting up a Development Environment == |
|||
The OLPC's software environment is a heavily modified Fedora 7 Linux system running a custom [[Sugar|GUI shell]] (Sugar). To develop for the platform you will eventually need access to a platform which runs in a manner substantially similar to the OLPC environment. Luckily there are many available options. |
|||
=== Option 1 - Emulated XO === |
|||
An [[Emulating the XO|emulated XO laptop]] is the recommended platform for "checking out" the Sugar environment, testing activities and for initial development of new activities. By installing an emulation package on your (reasonably powerful) host desktop, you can run an emulated version of the Sugar environment which is essentially the same code as runs on the real laptops. |
|||
An emulated XO does not provide tools such as SVG editors or Integrated Development Environments. You will normally run such software on your host machine and push the results onto the emulated machine. |
|||
The emulated XO has certain limitations with regard to the specialized hardware in the XO. See the Developer's FAQ below for some pointers on how to simulate the special hardware. |
|||
=== Option 2 - sugar-jhbuild === |
|||
This is what the core development team uses and is one of the most pleasant ways to work. Compared with using an Emulated XO, installing sugar takes more time and space to set up, and can be difficult to maintain, but results in a more flexible better environment. If you are intending to work on the core system/activities you will likely need to use sugar-jhbuild to set up your environment. See [[Sugar with sugar-jhbuild]] to get going. The 'native' environment for sugar-jhbuild is Fedora 7 and Ubuntu (feisty or gutsy). |
|||
[[Emulated Sugar-jhbuild|This approach]] also works nicely under emulation ([[Qemu]], [[Parallels]], [[VirtualBox]] or [[VMWare]]) on Linux, Windows or Mac OS host operating systems. This allows you to work without rebooting even when using sugar-jhbuild, and without risk of corrupting your host operating system. |
|||
==== On 32-bit Linux ==== |
|||
To get a working [[Sugar with sugar-jhbuild|Sugar using jhbuild]] you will need to be running an OS that provides compatible versions of the various libraries that Sugar requires (basically a very up-to-date Linux platform). |
|||
As of 2007-12-13 the distributions known to be able to support sugar-jhbuild are: |
|||
* [[Sugar_on_Fedora_7|Fedora 7]] |
|||
* [[Sugar_on_Ubuntu_Linux|Ubuntu Feisty Fawn (or Greater)]]. |
|||
* [[Sugar_on_Gentoo_Linux|Gentoo]] (with a trivial work-around) |
|||
At the moment, a Fedora 7 install with sugar-jhbuild is probably the most "sure" approach to getting a working full-speed (non-emulated) working environment for developing on Sugar with the latest libraries and solid upgrade path. As most of the core developers are working on Fedora boxes with sugar-jhbuild it is the most likely environment to be supported and continue to receive support. |
|||
==== On 64-bit Linux ==== |
|||
As of 2007-12-13 it is possible to build Sugar on 64-bit Linux with trivial workarounds/fixes. This has been confirmed on Gentoo amd64 and Debian Lenny (with the caveats below). |
|||
Sugar seems to be working on Debian Lenny (2007-11-05), though Python 2.5, even when installed, is not detected. Comment out the line '''jhbuild.commands.run('sanitycheck', config, [])''', line 95, to get it to install. |
|||
=== Option 3 - Native Sugar Packages on Linux === |
|||
As Sugar stabilizes and is ported to more distributions, it should be possible to use your Linux distribution's package management system to install Sugar. Distributions with ports so far: |
|||
* [[Sugar_on_Ubuntu_Linux#Option_3_-_Deb_Packages_for_Gutsy|Ubuntu Gutsy]] -- Note that we need more testing of this package-set, please let us know your experiences |
|||
If you don't see your distribution here, ask your distribution maintainers, or if you have the skills, create the packages yourself and submit them. |
|||
=== Option 4 - A real XO laptop === |
|||
Hardware Developer's Program - while there are only a small number of test units being produced, developers can [[Developers_Program#How_to_apply|submit proposals]] to receive one of those units for testing and development. |
|||
You can also, if you live in the US or Canada, and have sufficient funds, until Dec 31, 2007 use the Give 1 Get 1 program to acquire a production-run machine (and donate one to a child). |
|||
== Operating Environment == |
|||
Official description of the [[Software components]] on the laptop (XXX maybe merge this into that page, we want links to further information about each library, though?) |
|||
Development Languages: |
|||
* Python is strongly encouraged, to have a single language "under the hood" when the curious child looks inside |
|||
** C/C++ should be used where Python performance is unacceptable, but try to keep it to a minimum, preferably as standard well-encapsulated and documented components |
|||
* Smalltalk-speaking developers may wish to work within the eToys environment |
|||
* Javascript can be used in web-based applications (Gecko or Opera engine Javascript implementation) |
|||
GUI Environments: |
|||
* PyGTK or the PyGTK-derived [[OLPC Python Environment| Sugar]] system should be used for most "Window, Icon, Mouse, Pointer" type GUIs. Note, however, as of 2007-04-21 that the Sugar "graphics" package is in Flux. |
|||
* [[Pygame]] SDL-based 2D game environment can be used for "Canvas" graphics using "Sprites". |
|||
* (Mozilla) XULRunner can be used to develop Gecko-based activities |
|||
* [[EToys]] |
|||
Operating Stack: |
|||
* [[Hardware]] |
|||
* [[Firmware]] ([[Open Firmware]]) |
|||
* Fedora Core based Operating System |
|||
* [[Bitfrost]] Security System |
|||
* [[OLPC Python Environment|Sugar]] GUI Shell |
|||
Libraries/modules/services of note: |
|||
* [[D-BUS]] -- efficient Desktop-level RPC engine, most specialized laptop hardware and operations are exposed over DBus |
|||
* Telepathy (Glib, Salut, Gabble) -- collaboration/communications engine with "Tubes" (cross-machine RPC over DBus) and various network traversal and discovery logic, activities are encouraged to use Tubes where ever practical |
|||
* [[CSound]] -- acoustically modelled sound-synthesis engine (seen in the TamTam activity) |
|||
* Abiword -- collaborative text editor/word processor usable as a GTK widget that can be embedded in other activities |
|||
* [[SQLite]] -- lightweight relational database |
|||
* XULRunner (with Python DOM-capable bindings) -- Gecko 1.9 (Firefox 3.x) engine |
|||
* [[GStreamer]] -- general purpose media streaming platform, used for accessing the video camera and playing media |
|||
* Avahi -- discovery and advertising mechanism for mesh-hosted services |
|||
Common libraries not available: |
|||
* OpenGL |
|||
* Server-based relational databases (MySQL, PostgreSQL) |
|||
* If you are unsure whether something is supported, ask, or load up an emulated machine and check for the presence of the library |
|||
Testing/working: |
|||
* Announce your project on the [http://lists.laptop.org/listinfo/devel OLPC devel list] so that people know what you are working on and duplication of effort is reduced |
|||
* Add your project to the [[Software projects]] page |
|||
* Test your application in an official image (or a physical laptop) before publishing broadly |
|||
* To conserve memory or improve performance, consider replacing problematic areas in your Python code with C. For example, a [http://dev.laptop.org/ticket/1303 rewrite of the hardware manager service] in C saved 1.8 megabytes of private dirty memory. On a machine with only 256 megabytes of RAM and no swap space, efficient use of memory can make the difference between a usable system and a system made unreliable by out-of-memory failures. |
|||
* Distribute your source code under the GPL, LGPL or MIT license. |
|||
* When ready to test with real users add your activity to the [[Activities]] page to allow for easy download and installation |
|||
== Joining or Starting a Project == |
|||
Most developers will probably be working on an Activity for use on the OLPC. This kind of development can normally be done with little interaction with other development groups, save for the core Sugar developers (whose work directly affects activity developers). |
|||
=== Communications Channels === |
|||
Most of the core developers use IRC for instant-messaging-style communications: |
|||
irc.freenode.net #sugar #olpc #olpc-content |
|||
the Sugar mailing list is also used for broader comment and collaboration: |
|||
[http://mailman.laptop.org/mailman/listinfo/ List Information] |
|||
If you have a large number of developers in a given area and would like to set up a local discussion list, post to the Sugar mailing list with a request for a new discussion list. |
|||
Current Active Local Discussion Lists: |
|||
* [http://mailman.laptop.org/mailman/listinfo/argentina Argentina] |
|||
* [http://mailman.laptop.org/mailman/listinfo/brasil Brasil] |
|||
* [http://mailman.laptop.org/mailman/listinfo/india India] |
|||
* [http://mailman.laptop.org/listinfo/toronto-dev Toronto (Canada)] |
|||
* [http://groups.google.com/group/olpcnepal OLPC Nepal] |
|||
* [http://groups.google.com/group/dev-olpcnepal Developers OLPC Nepal] |
|||
'''Unofficial''' news and interesting tidbits often show up in the [http://planet.laptop.org blog aggregator] for the project. |
|||
=== Requests and Ideas for Projects === |
|||
[[Software ideas]] describes activity and tool types that are currently needed. If you have an idea for an activity, add it to the list in the appropriate category (create a new category if necessary). You can create a new wiki page to describe your idea in more detail. |
|||
=== Existing Projects === |
|||
[[Software projects]] describes the currently active projects that may need help. Once you have decided on a project, add yourself to the list along with your contact information, homepage (which may be a wiki page on the OLPC wiki), etceteras. In particular, the various [[Activities]] available on the XO may need help as build time draws near; if you're looking for an existing project to get your feet wet with, check there. |
|||
=== Available Resources === |
|||
The [[Developers Program]] provides general [[Project hosting| project management]] facilities for OLPC projects. |
|||
== Documentation == |
|||
As with most software projects, we have difficulties with documentation. We are '''very''' interested in finding people interested in documenting the system. If you are to shy about your coding skills to write code, helping us document the code-base would be an amazing and valuable contribution and might help you learn. |
|||
=== Tutorials === |
|||
See the [[Tutorials]] page for introductory and quick-start tutorials. Game developers will likely want to focus on: |
|||
* [[Game Development Newbies]] -- general introduction |
|||
* [[Game development HOWTO]] -- 5-minutes to your first activity in [[Pygame]] |
|||
=== References === |
|||
See the [[API Reference]] for pointers to the various libraries' reference documentation. |
|||
=== Resources === |
|||
* The [[:Category:Developers | Developer's Category]] collects everything in the wiki that's been tagged as pertaining to developers (it's a bit hard to navigate) |
|||
* [[Developers Program]] focuses on development for the core system, but with information useful for activity developers as well |
|||
* [[Sugar Code Snippets]] |
|||
Code worth reading: |
|||
*[http://dev.laptop.org/git.do?p=projects/block-party-activity;a=tree BlockParty] for overall organization of an activity. |
|||
*[http://dev.laptop.org/git?p=projects/hellomesh;a=summary HelloMesh], [http://dev.laptop.org/git.do?p=projects/connect-activity;a=tree Connect] or [http://dev.laptop.org/git.do?p=projects/write;a=tree Write] for tubes. |
|||
=== Frequently Asked Questions === |
|||
==== How do I do networking in Sugar? ==== |
|||
Recommended pattern for networking applications on the OLPC laptops is to use the Tubes/Telepathy system. This is basically DBUS remote procedure calls over telepathy networking. The Telepathy framework allows for session establishment and routing across strange network topologies. See [[Activity Sharing]] |
|||
* Can I wrap Tubes with a socket compatibility layer to get the NAT traversal features and the like, but use old socket-based code? ([http://lists.laptop.org/pipermail/sugar/2007-September/003331.html yes with caveats]) |
|||
The laptops will have IPv6 and IPv4 connectivity, they can use "normal" internet networking primitives as available in Python, Scheme and C. |
|||
* Standard Python supports synchronous and asynchronous networking including basic web-servers and the like. |
|||
* [http://www.twistedmatrix.com Twisted] will not be available by default on the laptops but partial installs of the framework could be included in your activities if you want to do lots of multi-protocol networking operations |
|||
* [http://pyro.sourceforge.net/ PyRO] (Python remote objects) is another common Python networking RPC approach. |
|||
* XMLRPC/SOAP can be used to produce [http://pywebsvcs.sourceforge.net/ web services] |
|||
==== How do I create a persistent server/service? ==== |
|||
* How do I register for start-time loading? |
|||
* Is there any dbus event service for loading only on response to messages? That is, not loading until there is an event of a given type, such as a presence event? |
|||
** Yes, of a sort, services are defined in .service files, these match a named service to an executable which is to provide that service. Thus one can register to handle requests for a given named service, but you still need to arrange to have that service called by something. |
|||
==== How do I access the special hardware? ==== |
|||
While Sugar will run on many machines, the OLPC-XO has some special hardware which can be exploited by software. |
|||
===== Camera / Camera-as-video-camera (v4l2) ===== |
|||
See [[GStreamer#Getting started|GStreamer]] for general instructions and [[Pygame wrapper#Camera|OLPCGames]] for Pygame-specific instructions. |
|||
===== Directional pad/buttons ===== |
|||
* Have their own X key names |
|||
* Currently 4-button set mapped to arrow (cursor) keys |
|||
* Two separate buttons mapped to ??? (pageup/pagedown) |
|||
* See [[Pygame_wrapper#Keyboard_and_Mouse|OLPCGames]] for Pygame-specific instructions, key layouts and discussion of using the directional pad for gaming situations |
|||
===== Touchpad / Glide Sensor ===== |
|||
* Shows up as a normal mouse under X. |
|||
* This is '''not''' a multi-touch capable glide sensor. |
|||
===== Drawing pad (stylus pad) ===== |
|||
* How to switch in/out of stylus mode? |
|||
* How to set interpretation parameters? |
|||
===== Audio-port probe ===== |
|||
Best sample code currently available is in the [http://dev.laptop.org/git.do?p=projects/measure;a=tree Measure Activity]. |
|||
* How to get access? |
|||
** You configure the ALSA mixer (using os.system in the example code) and then use [[gstreamer]] events to process a the incoming audio-buffer "handoff" using a fake data sink. You unpack the data from the string values and get integer values. (Or just use the utility class (AudioGrab) in the Measure Activity). |
|||
* What's going to come out when I get access (keeping in mind I (the developer) likely won't have the actual hardware available)? |
|||
** You are processing a stream of audio data. In the sample code you are configuring gstreamer to produce a stream of integers at 48000 Hz. You should be able to produce the same effect using gstreamer on any linux box using your normal microphone port. |
|||
===== Mode-switching code for the screen ===== |
|||
Much of this is controlled via the [http://dev.laptop.org/git.do?p=hardware-manager;a=blob;f=hardwaremanager.py;h=3154b17553621cc41fa947cbff2756372e6e37ec;hb=HEAD HardwareManager service] on DBUS. There is sample code for getting a reference to the hardware manager in the [http://dev.laptop.org/git.do?p=projects/read-activity;a=blob;f=readactivity.py;h=3eeb858cc5ea1dc67a60faee90628100479509be;hb=HEAD Read Activity], from there, simply call the dbus-exposed methods to set the values you want. HardwareManager controlled operations: |
|||
* Display Controller (DCON) data-source (CPU or DCON) |
|||
* DCON freeze/unfreeze |
|||
* backlight brightness |
|||
* keyboard light brightness |
|||
* color/black and white mode |
|||
How do we: |
|||
* set all 8 (4 distinct) settings for MODE_MONO_LUMA, MODE_CSWIZZLE, MODE_COL_AA (as distinct from just colour/black and white) |
|||
* query, change, and restrict screen orientation |
|||
* drop to a lower resolution for performance or ease of porting, such as 600x450 or 400x300 |
|||
See also [[Display]]. |
|||
==== How do I create my activity GUI? ==== |
|||
* Can I just use [[Cairo]], [[Pygame]] or [[GTK]] directly? |
|||
** PyGTK, Pango and PyCairo are the recommended GUI toolkit for coding new window/button/text/vector-graphics activities |
|||
** [[Pygame wrapper|Pygame]] is recommended for arcade-style raster-graphics games which need performance |
|||
** [[EToys]] can be used to produce sophisticated object-scripting GUIs, with support for rich media |
|||
* How can a non-GTK (or Qt) app fully interact with Sugar? |
|||
** At the moment the [[Low-level Activity API]] is quite involved |
|||
** Can be "fixed" by creating a wrapper in Python (e.g. the ClassicGnome activity with a performance and memory penalty) |
|||
** Can write various DBUS services using a GTK event loop to provide the required introspection services (implies that GTK must be loaded by every process, regardless of whether it is needed) |
|||
** Can alter your core event loop to cooperate with an embedded GObject event loop (PyGame allows this, for instance), with the small concern that this requires loading GObject into your process' memory space |
|||
* How flexible does the GUI need to be? |
|||
** Should be able to handle a resize-and-rotate event from the X server |
|||
** Should be able to handle internationalisation/localisation, including to right-to-left-written scripts |
|||
* What's the best development approach: |
|||
** Write outside Sugar, finish and debug, then port? |
|||
*** For older PowerPC-based Macs, this is likely the best approach |
|||
** Write to Sugar, test and debug within the system? |
|||
*** Usable if you can set up a reasonably-performing emulated system or upgrade your system to support Sugar directly |
|||
** Write directly on the XO |
|||
*** Usable if you are comfortable with command-line Linux editing tools, or want to use EToys. As [[Develop]] becomes available this should become more approachable. |
|||
==== How do I package my activity? ==== |
|||
* How do I work from an in-process activity (develop registration)? |
|||
** setup.py develop |
|||
** You can use sugar-activity to start the activity, but you have to manually close it (note that by default there is no way to easily kill a mis-behaving activity in Sugar) |
|||
* How do I produce a binary extension? |
|||
** On a workstation with Qemu, you can create a compilation workspace. (Using a Qemu qcow overlay lets you do this without corrupting your base OS image). Within that work-space, compile the packages you want using gcc, yum, and all the traditional tools. Package and upload the results. |
|||
* How do I share code between activities? |
|||
** How do I use (large, common) Python packages? |
|||
*** The system will "unify" common files across packages, so if you have a large package and another activity also uses that package then the system will only store one copy of the package (using a file-by-file comparison). |
|||
*** Numpy |
|||
*** Matplotlib |
|||
*** MySQL or PostgreSQL client code |
|||
*** Twisted |
|||
*** Zope Interfaces |
|||
*** Pygsear, PGU or other PyGame extensions |
|||
** How do I provide my own base packages on top of which I have written dozens of applications? |
|||
*** As with the common activities, the current plan is to have the system unify the packages on the laptop. There is a cost in that the packages must contain complete copies of their supporting framework for '''each''' activity. |
|||
==== How do I publish for others to download? ==== |
|||
* The [[Activities]] page is where most users will go to find new Activities |
|||
* Any http (web) server can be used to distribute packages |
|||
** Users can download a .xo package, when the package completes downloading, they use the Journal activity to "resume" the downloaded package |
|||
* How do I tell users about updates to the packages? |
|||
==== How do I share files between applications? ==== |
|||
Plan at the moment is to have file-sharing handled by the underlying system. That is, the system will simply notice that you have duplicate files with the same properties and hash and will share them between the two activities. |
|||
==== How do I test a Sugar activity? ==== |
|||
* Use the standard logging module in Python where possible |
|||
* Start your activity normally, its logs will be sent to the ~/.sugar/default/logs/ directory named after your Activity's DBUS service |
|||
* You can use the built-in [[Log Viewer]] activity on production XO versions (build 649 and up), alternately you can just view the logs in a developer's console using less or vi |
|||
* If you like you can also use: |
|||
sugar-jhbuild shell |
|||
sugar-activity YourActivityName |
|||
to run your activity from a shell and be able to drop into pdb or similar command-line debuggers. |
|||
==== How do I debug a Sugar activity? ==== |
|||
If you start your Sugar activity from the command line (see above), you can insert a standard Python: |
|||
import pdb |
|||
pdb.set_trace() |
|||
command into your activity and then use the Python debugger to step through your activity's behaviour. Note that this will "freeze" your application while you are working, so you may have display issues. |
|||
==== How do I edit with emacs on the laptop? ==== |
|||
* Install [http://www.mtxia.com/fancyIndex/Tools/Editors/MicroEMACS/ MicroEMACS] by copying [http://www.mtxia.com/fancyIndex/Tools/Editors/MicroEMACS/me404linux.bin this file] to the laptop. |
|||
* [http://zile.sourceforge.net/ Zile] may be closer to what you expect from Emacs install this RPM [ftp://rpmfind.net/linux/fedora/extras/6/i386/zile-2.2.19-1.fc6.i386.rpm this rpm file] to get it. |
|||
==== How do I mount a USB drive? ==== |
|||
Normally this is done automatically by the HAL when you plug the USB key into the laptop. It will show up as a directory in the /media folder. If, however, you had the USB key in when you started the machine, or the HAL doesn't recognize the key, you may not get the mount completed. In that case you can try manually mounting the key: |
|||
* Enter the linux shell mode |
|||
* First become root: <tt>$ su</tt> |
|||
* Then make a place to mount it: <tt>$ mkdir /mnt/usb</tt> |
|||
* Then mount the drive: <tt>$ mount /dev/sda1 /mnt/usb</tt> |
|||
* Don't forget to unmount it before removal: <tt>$ umount /mnt/usb</tt> |
|||
* If anything fails you should edit your <tt>/etc/fstab</tt> file to include the mount point, device, and filesystem for the device to mount. |
|||
==See also== |
|||
*[[Creating an activity]] |
|||
*[[Game development HOWTO]] |
|||
[[Category:Developers]] |
|||
[[Category:Software development]] |
|||
[[Category:Emulation]] |