Developer Images

From OLPC
Revision as of 13:02, 8 April 2007 by Mcfletch (talk | contribs) (Add link to Red Hat's SDK LiveCDs)
Jump to: navigation, search

Developer Images (Quickstart Images)

Developer images are intended to provide a development environment in which you can immediately begin developing Sugar activities (applications). They are full desktop installations with Sugar pre-built which can be downloaded and run on Linux or Win32 machines using the free (0 cost, proprietary) VMWare Player application.

Note: The images have far more software than the OLPC XO Laptops, so you need to be careful not to rely on libraries in the image! The images are also provided by members of the community. They are not necessarily "official" OLPC images.

Red Hat SDK LiveCDs

Created by John (J5) Palmieri

Available for direct download from Red Hat, these are minimal development environments (about 291MB) that have full sugar environment, gcc, gcc-c++, gdb, oprofile and oprofile-gui. We also have a Classic GNOME activity which launches a GNOME session which includes Nautilus, Metacity, gnome-volume-manager for automounting of external media, gedit, vim-x11, nautilus-open-terminal and gnome-terminal.

These builds are much closer to a regular laptop installation image than the other developer's images. That is, they tend to have less software installed, though there are still lots of packages not available on the laptop.

Fedora Core 6 Build

Created by Noah Kantrowitz (kantrn [] rpi [] edu):

I have put together a disc image with a stock install of FC6 (using the Software Development package set) and Sugar already up and running. The compressed image is 1.7G, and is available using:

wget http://dev.laptop.org/~krstic/olpcdev-fc6.img.gz

Note: the server is not properly configured to allow downloading via many web browsers.

Uncompressed it should be just under 6G. I tried to install as much as possible using yum, but Python 2.5 and anything with a Python extension were compiled by hand.

Use olpc/password to login. The only thing not working on it is Etoys, as at the time I did the final build it was broken in git. If you have any questions about it, please don't hesitate to ask.

Second Release (v2)

This is simply an improved version of the v1 images. It still uses Gentoo x86 as its base, but it splits out the high traffic Portage directories into a separate disk image so that the core image is 3GB instead of 4GB on-disk. The sugar build is updated to current, though the TamTam and Etoys activites are still broken (due to missing csound and unresolvable source address respectively).

The image now includes a copy of the HelloWorld activity (with a few minor enhancements) and a few useful bookmarks in the Firefox instance. The Sugar activity is also now launched with a console so that it is easier to switch to that console to kill the Sugar system.

Linux Tracker has the torrent download.

Initial Release Images (v1)

This is a VMWare image of a Gentoo desktop upgraded to support the Sugar environment from the One Laptop Per Child project. The build directories for Sugar are intact so that you can upgrade to the latest Sugar releases in the same manner as the core developers do (by re-running sugar-jhbuild and skipping any failing projects).

To run the image you will need to unpack it (tar -xzvf) into a directory with at least 8 GB of free space. The image was created with VMWare Workstation 5.5 on Linux.

Username/password for the image is olpcwork/olpcwork. Launch Sugar using the XO (child) icon on the desktop, but keep in mind that Sugar is full-screen and includes no mechanism for closing, so you'll likely want to keep at least one other window open to which to alt-tab in order to kill Sugar when you are finished.

  • Gentoo (up to date stable build with just the required ~x86 packages, based off a 2006.1 (latest) profile)
  • Disk Image: 3GB compressed, 7GB uncompressed, Internally: 8GB sparse, 4GB of that used as far as the embedded OS is concerned
  • 256MB RAM allocated in the image
  • Performance is quite reasonable for editing code and testing Sugar on a host with reasonable (1GB) ram and processor (2GHz Athlon64)
  • Gnome desktop incl. Firefox 2.0.0.2
  • Sugar built and ready-to-run
  • Common developer's tools installed (source code control systems, gcc, vim, Eric3, Inkscape)
  • Networking works reasonably well (uses nonstandard NetworkManager for the networking system, as in Sugar itself)

The target market for this image is developers on Win32 or Linux who just want to start working on Sugar. Provides the ability to unpack, run and start working with Sugar in a reasonable development environment with mature tools available.

LinuxTracker site has the torrent-based download.

Toquito LiveCD Builds (Upcoming)

Intended to use Aufs to allow for a static base image with a dynamic overlay image. Coming soon.

Startup Questions

  • What is needed?
  • How do I do networking in Sugar?
    • Internal (to other laptops)
    • External (to the wider internet)
    • Activity Sharing (session establishment)
    • Otherwise general Python networking
      • Twisted (will this be available on the images?)
      • Asyncore
      • PyRO (Python remote objects)
      • XMLRPC/SOAP
  • 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?
  • How do I access the special hardware?
    • Camera
      • Have to script v4l2 via gstreamer to capture a single frame from the camera. See sugar/shell/intro/glive.py for sample code
    • Camera-as-video-camera (v4l2?)
      • Is a regular v4l2 device available via gstreamer (gst module)
    • 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)
    • Touchpad
    • Drawing pad (stylus pad)
      • How to switch in/out of stylus mode?
      • How to set interpretation parameters?
    • Audio-port probe
      • How to get access?
      • What's going to come out when I get access (keeping in mind I (the developer) likely won't have the actual hardware available)
    • Mode-switching code for the screen
      • backlight on/off
      • backlight brightness
      • set all 8 (4 distinct) settings for MODE_MONO_LUMA, MODE_CSWIZZLE, MODE_COL_AA
      • query, change, and restrict screen orientation
      • drop to a lower resolution for performance or ease of porting, such as 600x450 or 400x300
  • How do I create my activity GUI?
    • How does HippoCanvas work?
    • Can I just use Cairo or GTK directly?
    • How can a non-Python app fully interact with Sugar?
      • At the moment it cannot. This appears to be an arbitrary restriction that can currently be "fixed" by creating a wrapper in Python. Basically Sugar is using custom dbus messages to communicate with a server that must be present for every activity. AFAICS there's no real reason to do that, as all that's communicated is "which bundle did we start", which Sugar knows before it starts the bundle.
    • How flexible does the GUI need to be? (e.g. resize and rotate)
    • How do I share code between activities?
    • What's the best development approach:
      • Write outside Sugar, finish and debug, then port?
      • Write to Sugar, test and debug within the system?
  • 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 (using the Sugar GUI: show the frame, then move to the activity icon on the top bar, hover for a second, then click close (yes, it's really that awkward))
    • How do I produce a binary extension?
    • How do I make my package available for users to download dynamically?
    • How do I tell users about updates to the packages?
  • How do I get access to user-generated content (share files between applications)?
  • 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
  • How do I debug a Sugar activity?
  • How do I create an asymmetric application? (Publisher for others to consume)

Developer's Starting Points

Beginning to collect documentation here for components the new activity/Sugar developer needs to be familiar with. This isn't the correct spot for it, move to the correct spot when I figure out what that is.

  • Sugar Architecture covers Sugar APIs and specifications
  • 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
  • Software components is a somewhat old document describing the various pieces of software and libraries involved in the system.
  • Sugar PyDoc just provides the raw API documentation, which is severely lacking in documentation strings (Good familiarisation project might be working with Marco to improve that situation)
  • Hippo PyDoc again, just raw API documentation, needs lots of documentation effort
  • Instructions on using the Sugar user interface
  • Human interaction guidelines (HIG) for Sugar activities
  • Tutorial to create a new activity
  • Sugar Code Snippets
  • Understanding sugar code provides an overview of how Sugar interacts with activities, including startup and shutdown, useful to understand the environment in which your activity will run
  • Software projects discusses the various sub-projects, good place to go to find out where you may be needed XXX would be nice to have an area for advertising particular needs as well
  • Bitfrost the security system which will control activities and their interaction with the system and other users
  • 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)
  • Activity Bundles describes the packaging structure