Sugar Architecture Temp: Difference between revisions
No edit summary |
No edit summary |
||
Line 16: | Line 16: | ||
* a top level X window with some predefined properties, see [[Low-level Activity API#X Properties]], |
* a top level X window with some predefined properties, see [[Low-level Activity API#X Properties]], |
||
* behaves properly when running inside [[Rainbow]], |
* behaves properly when running inside [[Rainbow]], |
||
* saves its state to the Datastore when needed, |
* saves its state to the Datastore when needed, see [[Low-level_Activity_API#Datastore]], |
||
* can resume that state so the user is confronted with the same state as when the activity was closed, |
* can resume that state so the user is confronted with the same state as when the activity was closed, |
||
* provides a D-Bus service that the shell can use, see [[Low-level_Activity_API#DBus Methods]], |
|||
* |
|||
One activity maps to one top-level X window, but for window management be more complete, the activity should also provide the shell with an icon (in this format: [[Sugar Icon Format]]) and an user-visible name translated according with the current locale. |
|||
Also, the shell will need access to a D-Bus service associated to that window. See [[Low-level Activity API]]. |
Also, the shell will need access to a D-Bus service associated to that window. See [[Low-level Activity API]]. |
Revision as of 19:02, 28 January 2008
Please copy/paste "{{Translationlist | xx | origlang=en | translated={{{translated}}}}}" (where xx is ISO 639 language code for your translation) to Sugar Architecture Temp/translations | HowTo [ID# 102682] +/- |
The Sugar Interface acts as the primary user interface for most children using an OLPC laptop. It runs as a graphical shell on top of a trimmed down implementation of Redhat's Fedora implementation of a Linux operating system. Python has been selected as the primary development language for sugar.
Components
Activities
What are called applications or programs in other environments, are activities in Sugar, see OLPC Human Interface Guidelines/Activities.
Activity authors need to understand how the activity concept is different from traditional applications and how its software can make better use of the Sugar platform.
Activities can happen in isolation or in collaboration with other users.
What is a correct activity:
- a top level X window with some predefined properties, see Low-level Activity API#X Properties,
- behaves properly when running inside Rainbow,
- saves its state to the Datastore when needed, see Low-level_Activity_API#Datastore,
- can resume that state so the user is confronted with the same state as when the activity was closed,
- provides a D-Bus service that the shell can use, see Low-level_Activity_API#DBus Methods,
Also, the shell will need access to a D-Bus service associated to that window. See Low-level Activity API.
Shell
The Sugar Shell is the UI component that provides the following services to the user:
- starting, stopping and joining activities,
- managing devices (network connection, battery, etc),
- managing the clipboard,
- managing groups of buddies.
Basically, all that the user does outside activities is done in the shell.
The shell can be divided in two major components, the Frame and the Home view.
Shell service
The shell service provides the following subservices to the Shell:
- clipboard: store clippings, this is basically the backend of the clipboard tray in the left frame,
- activity registry: keeps track of installed activities,
- object type registry: maintains a mapping of mime type to "umbrella" types, these are high level object types like Image, Audio, Video, etc that are used to give the user an uniform view of objects in the clipboard and in the journal.
These services are offered as D-Bus interfaces.
Journal
The Journal keeps track of what the user has done with the laptop. Every activity should keep records in the journal so the user can see what has been done in the past and probably resume some past activity.
All this data produced by the activities is kept by the Datastore service, and the journal provides to the user different ways of querying and browsing past works.
Datastore service
Provides activities with a way to store data and metadata and the journal with means for querying, including full text search.
Presence service
This service allows the shell to
Specifications
API
- Low-level Activity API
- Presence Service DBus API
- HippoCanvas: Cairo drawing and UI layout widget
Third party packages
- Avahi service discovery layer
- Cairo 2D graphics library (Python interface)
- Pango text layout library (Python interface)
- GTK+ user interface (Python interface)
- D-Bus interprocess communications system (Python interface)