Activity bundles: Difference between revisions
DanWilliams (talk | contribs) (→Activity Bundles: reorganize section names) |
DanWilliams (talk | contribs) (add info about locations) |
||
| Line 4: | Line 4: | ||
= Rationale = |
= 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. |
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 = |
= Bundle Structure = |
||
| Line 16: | Line 21: | ||
(the images, sounds, and bin subdirectories are not required, but are shown as examples of how an activity may wish to organize its resources) |
(the images, sounds, and bin subdirectories are not required, but are shown as examples of how an activity may wish to organize its resources) |
||
= .info File Format = |
|||
Revision as of 00:11, 1 September 2006
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)