Getting started programming: Difference between revisions
(→Option 3 - A real XO laptop: No point advertising it, doesn't seem likely we'll fix it now with G1G1 machines arriving) |
(Update for current status, clean up, answer some questions) |
||
Line 1: | Line 1: | ||
{{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 |
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> |
|||
<div style="float:right"> |
|||
__TOC__ |
__TOC__ |
||
</div> |
</div> |
||
Line 69: | Line 69: | ||
:''We should have an article for this. [[User:MitchellNCharity|MitchellNCharity]] 09:54, 18 October 2007 (EDT)'' |
:''We should have an article for this. [[User:MitchellNCharity|MitchellNCharity]] 09:54, 18 October 2007 (EDT)'' |
||
=== Option 3 - |
=== 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. |
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 == |
== Operating Environment == |
||
Line 79: | Line 89: | ||
Development Languages: |
Development Languages: |
||
* Technically any language is usable |
|||
* Python is strongly encouraged, to have a single language "under the hood" when the curious child looks inside |
* 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 |
** 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 |
* 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) |
* Javascript can be used in web-based applications (Gecko or Opera engine Javascript implementation) |
||
Line 134: | Line 143: | ||
Most of the core developers use IRC for instant-messaging-style communications: |
Most of the core developers use IRC for instant-messaging-style communications: |
||
irc.freenode.net #sugar |
irc.freenode.net #sugar #olpc #olpc-content |
||
the Sugar mailing list is also used for broader comment and collaboration: |
the Sugar mailing list is also used for broader comment and collaboration: |
||
Line 165: | Line 174: | ||
== Documentation == |
== 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 === |
=== Tutorials === |
||
See the [[Tutorials]] page for introductory 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 === |
=== References === |
||
Line 179: | Line 193: | ||
* [[Developers Program]] focuses on development for the core system, but with information useful for activity developers as well |
* [[Developers Program]] focuses on development for the core system, but with information useful for activity developers as well |
||
* [[Sugar Code Snippets]] |
* [[Sugar Code Snippets]] |
||
* [[Getting involved in OLPC]] - general guide to where help is needed, though written a while ago, before direct development was particularly easy (thus the emphasis on working on upstream projects AFAICS) |
|||
⚫ | |||
Code worth reading: |
Code worth reading: |
||
Line 207: | Line 219: | ||
==== How do I access the special hardware? ==== |
==== 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) ===== |
===== Camera / Camera-as-video-camera (v4l2) ===== |
||
See [[GStreamer#Getting started]]. |
See [[GStreamer#Getting started|GStreamer]] for general instructions and [[Pygame wrapper#Camera|OLPCGames]] for Pygame-specific instructions. |
||
===== Directional pad/buttons ===== |
===== Directional pad/buttons ===== |
||
* Have their own X key names |
* Have their own X key names |
||
* Currently 4-button set mapped to arrow (cursor) keys |
* Currently 4-button set mapped to arrow (cursor) keys |
||
* Two separate buttons mapped to ??? (pageup/pagedown) |
* 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 |
|||
* Specially named keys in the PyGame port |
|||
===== Touchpad / Glide Sensor ===== |
===== Touchpad / Glide Sensor ===== |
||
Line 222: | Line 238: | ||
===== Drawing pad (stylus pad) ===== |
===== Drawing pad (stylus pad) ===== |
||
* How to switch in/out of stylus mode? |
* How to switch in/out of stylus mode? |
||
* How to set interpretation parameters? |
* How to set interpretation parameters? |
||
Line 254: | Line 271: | ||
* Can I just use [[Cairo]], [[Pygame]] or [[GTK]] directly? |
* 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 |
|||
** Sugar's own GUI interface is coded in a GTK derived library (Hippo), using an internal "sugar.graphics" package. This package is currently in flux and you should not likely start new projects using it until the API stabilises. In the meantime please use GTK or PyGame (SDL) for you project's GUI. |
|||
** [[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? |
* How can a non-GTK (or Qt) app fully interact with Sugar? |
||
** At the moment |
** At the moment the [[Low-level Activity API]] is quite involved |
||
⚫ | |||
** Sugar is using custom dbus messages to communicate with a server that must be present for every activity. That restriction may be relaxed in the future. |
|||
⚫ | |||
⚫ | |||
⚫ | |||
⚫ | |||
⚫ | |||
* How flexible does the GUI need to be? |
* 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 a resize-and-rotate event from the X server |
||
Line 269: | Line 287: | ||
** Write to Sugar, test and debug within the system? |
** 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 |
*** Usable if you can set up a reasonably-performing emulated system or upgrade your system to support Sugar directly |
||
** Write directly on the XO |
|||
* How does [[HippoCanvas]] work? |
|||
*** 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 package my activity? ==== |
||
* How do I work from an in-process activity (develop registration)? |
* How do I work from an in-process activity (develop registration)? |
||
** setup.py develop |
** 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) |
** 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? |
* 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 make my package available for users to download dynamically? |
|||
⚫ | |||
* How do I share code between activities? |
* How do I share code between activities? |
||
** How do I use (large, common) Python packages? |
** How do I use (large, common) Python packages? |
||
Line 286: | Line 305: | ||
*** Twisted |
*** Twisted |
||
*** Zope Interfaces |
*** Zope Interfaces |
||
*** Pygsear or other PyGame extensions |
*** Pygsear, PGU or other PyGame extensions |
||
** How do I provide my own base packages on top of which I have written dozens of applications? |
** 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. |
*** 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. |
||
⚫ | |||
* 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 share files between applications? ==== |
==== How do I share files between applications? ==== |
||
Line 295: | Line 321: | ||
==== How do I test a Sugar activity? ==== |
==== How do I test a Sugar activity? ==== |
||
* Start sugar, start a bash shell, run "sugar-jhbuild shell" to set up the sugar environment variables, then use "sugar-activity YourActivityName" to run the activity with output going to your local shell |
|||
* 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? ==== |
==== How do I debug a Sugar activity? ==== |
||
If you start your Sugar activity from the command line, you can insert a standard Python: |
If you start your Sugar activity from the command line (see above), you can insert a standard Python: |
||
import pdb |
import pdb |
||
Line 305: | Line 340: | ||
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. |
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? ==== |
==== How do I edit with emacs on the laptop? ==== |
||
Line 325: | Line 358: | ||
==See also== |
==See also== |
||
*[[Creating an activity]] |
*[[Creating an activity]] |
||
⚫ | |||
[[Category:Developers]] |
[[Category:Developers]] |
Revision as of 17:37, 13 December 2007
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.
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
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)
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 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 emulated XO laptop is the recommended platform both for "checking out" the Sugar environment and for developing 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). This approach also works nicely in VMWare on Windows or Mac OS, on recent hardware you don't need to dual boot.
On 32-bit Linux
sugar-jhbuild no longer supports building "base" libraries, so to get a working Sugar using jhbuild you will need to be running an OS that provides compatible versions of the various libraries that Sugar requires.
As of 2007-12-13 the distributions known to be able to support sugar-jhbuild are:
- Fedora 7
- Ubuntu Feisty Fawn (or Greater).
- Gentoo (with a trivial work-around)
It is also possible to run one of these "just works" distributions in emulation under another operating system (Windows/Mac/Linux) using any of a number of emulators (Qemu, Parallels,, VMWare).
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 2b - sugar-jhbuild on emulated Fedora 7
Run Fedora 7 in emulation, and then sugar-jhbuild on top of that.
- We should have an article for this. MitchellNCharity 09:54, 18 October 2007 (EDT)
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:
- 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 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 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
- 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 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 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:
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:
Unofficial news and interesting tidbits often show up in the 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 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 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:
- BlockParty for overall organization of an activity.
- HelloMesh, Connect or 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? (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.
- 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
- PyRO (Python remote objects) is another common Python networking RPC approach.
- XMLRPC/SOAP can be used to produce 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 for general instructions and 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 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 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 HardwareManager service on DBUS. There is sample code for getting a reference to the hardware manager in the 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?
- 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.
- Write outside Sugar, finish and debug, then port?
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 use (large, common) Python packages?
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?
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 MicroEMACS by copying this file to the laptop.
- Zile may be closer to what you expect from Emacs install this 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: $ su
- Then make a place to mount it: $ mkdir /mnt/usb
- Then mount the drive: $ mount /dev/sda1 /mnt/usb
- Don't forget to unmount it before removal: $ umount /mnt/usb
- If anything fails you should edit your /etc/fstab file to include the mount point, device, and filesystem for the device to mount.