Activity bundles

Introduction

Every activity in the Sugar environment is packaged into a self-contained "bundle". The bundle contains all the resources and executable code (other than system-provided base libraries) which the activity needs to execute. Any resources or executable code that is not provided by the base system must be packaged within the bundle.

Rationale

Activities are meant to be shared between children. If a child doesn't have the activity, it is automatically transfered to the child when he or she joins the shared activity. Packaging activities in self-contained bundles allows easy sharing, installation, removal, and backup.

Location

Activities are installed and removed automatically by Sugar, in response to user actions. Sugar places activities in directory of its choice, currently $(prefix)/share/sugar/activities. Activities should not rely on being installed in a specific location, and should use relative paths where paths are necessary (i.e., for shared library linkage, activity resources such as images, sounds, etc). Sugar will automatically generate and remove the .service files necessary to launch the activity through D-Bus service activation when the activity is installed or removed.

Activities should also NEVER store local state or preferences in the activity bundle itself. These should always be stored in an activity-specific directory in the user's sugar profile, available through the SUGAR_PROFILE environment variable.

Bundle Structure

The activity bundle is a directory, with a name ending in ".activity". Each activity bundle must, in its root directory, contain a file with the same name as the activity bundle, but ending in ".info" rather than ".activity", and following a special format. For example:

Drawing.activity/
    Drawing.info
    drawing-activity.svg
    images/
    sounds/
    bin/

(the images, sounds, and bin subdirectories are not required, but are shown as examples of how an activity may wish to organize its resources)