Glossary

From Sugar Labs

Jump to: navigation, search

Below are word terms or abbreviations collected from team or project glossaries (Category:Glossary).

Sugar Labs Glossary

Acronym	Name/link	Notes
	Sugar	Sugar Labs software for learners
SP	Sugar Platform	A set of versioned components on which activity authors can rely when targeting their activities to run on a particular Sugar version
IAEP	It's an Education Project	A discussion mailing list for Sugar and the learning theories that it espouses
ASLO a.sl.o	Activity Library	The collection of Sugar Activities on http://activities.sugarlabs.org (activities.sugarlabs.org)
AMO	Mozilla Add-ons	Mozilla Add-ons, also known as AMO, is a resource for finding and installing add-ons for Mozilla products. ASLO is based on AMO code.
	Sweet sweet	The abstract design of the Sugar interface, and by extension—the learner experience. A codified implementation of Sugar software is called a sweet within the Platform infrastructure.
	Glucose	The base Sugar software environment
	Fructose	A set of demonstration Activities in Sugar
	Sucrose	Glucose plus Fructose makes a basic Sugar working platform
	Ribose	The hardware-specific software components developed to support the distribution of Sugar
	Starch	A complete disk image for Sugar
TA	Turtle Art activity	Turtle Art is an activity with a Logo-inspired graphical "turtle" that draws colorful art based on Scratch-like snap-together visual programming elements.
SoaS	Sugar on a Stick	A complete Sugar environment supplied to run on a USB/SD flash memory drives. Also, used casually, the disc image supplied for that purpose, but used on other media. Sugar in a Fedora or other-based Live GNU/Linux distribution
XS	XO school Server	The XO school Server, or XS, is one of the products of the OLPC project, designed to complement the OLPC XO laptop or other system running Sugar. It is a GNU/Linux-based OS (a Fedora-based distribution) engineered to be installed on generic, low-end servers.

Sweets Platform

A list of terms to understand the basic concepts of Sweets.

Zero Install, 0install

Decentralized cross-distribution software installation system that Sweets is based on.

Sweets

Package management wrapper around Zero Install.

sweet, sweet project

Distribution entities in Sweets, i.e., packages. In other words, software projects that have recipe files in their sources that are being released via Sweets.

feed

A file in XML notation that contains information about all possible variants of the software, i.e., implementations, that can be launched.

interface

This is the cornerstone of Zero Install and, thus, Sweets, as well. To make a feed useful for other people, they are placed somewhere on the Internet to be accessible via HTTP/FTP (http://sweets.sugarlabs.org for the Sweets case). The full Web url, such as http://0install.net/2006/interfaces/ZeroInstall-GUI.xml, is a unique identifier of a distribution entity within Zero Install/Sweets. This powerful identifier is named the interface.

This url is all that is needed to run software from everywhere there is a connection to the Internet.

implementation

One or several bundles that contain one particular implementation of software projects that are being distributed via Zero Install. Implementations are attributed with versions, stability levels, targeted machine architectures, and OS types. It is possible to have several implementations for the same software version if there are differences between launching them on different OSes or machine architectures. Another important attribute of implementations are dependencies of this particular implementation, formed as a list of interfaces. Feeds contain information about all existing implementations in order to let Zero Install choose the right one on the client side, taking into account tons of details, like machine architecture, OS type, stability levels, or dependency restrictions.

recipe

On the Zero Install level, developers work with feeds manually. In the Sweets case, the regular way is to use recipes (but it is still possible to fallback to using feeds at any time). In short, it is an analog of spec files in GNU/Linux distributions, e.g., RPM .spec files or debian/ directories in Debian. Recipes do not specify ready-to-launch implementations like feeds do, but rather, only describe the lastest software version. The feed will be generated automatically on a server (along with preserving the history of versions) after releasing a new version of the software.

Short form for sweet interfaces

Within Sweets, it is possible to omit the http://sweets.sugarlabs.org/ prefix for sweet interfaces so as to make usage more expressive, e.g., in recipe files. It is always possible to use the full interfaces.

Implemented interfaces

One particular sweet implements one or several interfaces according to its recipe files. The reason for having several interfaces is that the same sweet might represent itself, e.g., http://sweets.sugarlabs.org/~alsroot/browse, and the upstream sweet that was used as a basis for the current one, e.g., http://sweets.sugarlabs.org/browse. Furthermore, on the client side, it will be possible to get implementations from ~alsroot/browse while launching browse sweet.

Associated interfaces

Associated interfaces is the alternate way to setup upstream-downstream relations between interfaces. If a recipe file mentions some interfaces as associated, implementations from these interfaces will be added to the implementations list of the current one. For example, if the http://sweets.sugarlabs.org/sdk/sugar interface (the pure sweet Sugar Shell) contains http://sweets.sugarlabs.org/base/sugar (an alias to the natively packaged Sugar Shell) as an associated interface, it will be possible while launching sdk/sugar, to run natively packaged sugar that came from base/sugar.

local sweet

It is an important high-level concept in Sweets, which is intended to make the development process of sweet projects more comfortable. Technically, it is the source software of the sweet project (i.e., with a recipe file) placed somewhere in the file system and registered in the local Sweets instance as a single implementation for interfaces it implements. It is always possible to run this local sweet directly by using the full filesystem path as an interface, but its most useful feature is reuse of the local implementation in routine Sweets workflows. For example, if the sugar-toolkit sources, which implement the sdk/sugar-toolkit interface, were cloned to the ~/src/sugar-toolkit directory, then, while running a sdk/sugar sweet, it would become possible to reuse local sugar-toolkit sources as a regular implementation of the sdk/sugar-toolkit dependency of sdk/sugar.

sweet package

Using the http://packages.sugarlabs.org Web UI, it is possible to create a repository with native packages from released sweets.

Sweets Distribution

It is a repository with Glucose and Fructose sweet packages based on dextrose/sugar sweets.

Activity Library

Submitted activity

Activity is only Submitted if its not Completed. Accessible only for author.

Completed activity

To complete Submitted activity

click Change Status option in Developer Tools menu
complete all criteria
click Complete Activity button

After that, activity will be marked as an Experimental.

Experimental activity

Completed but not yet Public activity. Before installing this activity user will be warned about experimental nature of this activity. To get these activities in lists, user should enable "show experimental activities" checkbox.

Nominated activity

To nominate Completed activity

click Change Status option in Developer Tools menu
complete all criteria
click Nominate Activity button

After that, broadcast event will be send to editors. Someone of them will review activity and push it to the public.

Public activity

Activity which was reviewed by editor and pushed to the public. It is accessible for all users.

Documentation Team

A Sugar Taxonomy

Sweet: The abstract design of the interface
Glucose: The base Sugar environment
Fructose: A set of demonstration activities
Sucrose: The interface, plus a set of demonstration activities
Ribose: The base Linux distribution being used by Sugar
Starch(es): A complete disk image for Sugar

Networking

mesh network: A wireless mesh network is a communications network made up of radio nodes in which nodes can forward information on behalf of each other so that even nodes that are not in direct radio contact can communicate via nodes that are between them. The collective coverage area of the radio nodes working as a single network becomes a mesh cloud.
infrastructure mode: network connectivity through a Wi-Fi access point, e.g., 802.11b/g
mesh mode: network connectivity through a mesh network, e.g., 802.11s
simple mesh mode: a mesh network that is running between laptops without a School Server
school server mesh mode: a mesh network that is mediated by a School Server
presence: a discovery service for finding other laptops on the network
jabber: a protocol that the laptop uses for collaboration
tubes: a protocol for passing data between laptops
mesh channel: the laptops use three channels for communication: 1, 6, and 11; in simple mesh mode, the laptops can only see other laptops on the same channel; in a School Server mesh, laptops on all channels are visible
access point (AP): an AP is a device that connects wireless communication devices together to form a wireless network. The AP usually connects to a wired network and can relay data between wireless devices and wired devices. Several APs can link together to form a larger network.
mesh portal point: a mesh node that serves as a gateway (portal) to a network external to the mesh

Operating system

operating system (OS): The low-level system that manages the various files, processes, etc. needed to operate the laptop; the OS used by the XO laptop is the RedHat Fedora distribution of Linux.
build: a specific instance of the operating system, designated by category and number; e.g., OLPC Update.1-703; OLPC Joyride-1792; Ubuntu 8.4 Hardy Heron; Fedora 9

Internal storage

datastore: component that manages the access to the data displayed in the Journal; these data are stored in individual files; an index that contains the metadata and speeds up searches

External storage

flash memory device/USB stick/jumpdrive/thumb drive/USB drive: A small, external storage device that plugs into one of the USB ports on a computer. They can store between 16 MB (enough to hold several music files) up to 32 GB (enough to hold multiple high quality full-length movie files) and a wide range in between. Flash drives are easily purchased at any electronic store starting as low as $5 to $10.
SD card: Secure Digital (SD) is a flash (non-volatile) memory card format used in portable devices, including digital cameras, hand-held computers, PDAs, and mobile phones. SD card capacities range from 8 MB to 32 GB.

User Interface (UI)

A User Interface is defined by Wikipedia as "the aggregate of means by which people—the users—interact with the system—a particular machine, device, computer program or other complex tools. The user interface provides means of:

Input, allowing the users to manipulate a system
Output, allowing the system to produce the effects of the users' manipulation."

So, the Sugar user interface is all the icons and words and the screen they appear on, in addition to the keyboard, mouse, and touchpad buttons used to interact with those icons and words.

Because, the Sugar learning philosophy strives to integrate every part of the system into a coherent learning tool, we emphasize the learning over other other uses, and tend to substitute Learners for 'Users' when we speak of the people in our community.

Sugar UI: the user interface of the laptop is called “Sugar”; it consists of four views, the Frame, and the Journal
Home view: a view of what activities you are running and other status information;
Group view: a view of your friends with whom you are working on shared projects;
Neighborhood view: a view of who is on the network with you and what activities and content are being shared. The Network view is the starting screen on the XO-1 laptop.;
Activity view: a view used by the current activity that is running on the laptop
Frame: the Frame, which can appear in any view, holds a clipboard, the task bar (for starting activities), navigation controls, and list of “buddies” (collaborators);
Journal: an special activity where you can see your previous work done in other activities. You can also resume the work done at those activities;
toolbox: an user-interface element that appears in the top part of most activities and contains one or more toolbars
toolbar: an user-interface element that can contains several buttons, text entry fields, drop-down menus, etc. that is usually contained in a toolbox; common examples of toolbars include: Activity, View, Edit, et al.
palette: a black box that appears when the mouse hovers over an object; a palette can contain the name of the control, some details about it or some related actions

Activities and Content

activity: an application that has an icon in the taskbar, e.g., Write, Record, Browse; Activities engage you in taking a picture, reading a book, creating a page, annotating a page, animating a drawing, making sounds and music, measuring and sensing, sharing your favorites, inviting your friends, surfing on the web, etc...
content: books, music, movies, photographs, drawings, etc. that are created on the laptop or downloaded to the laptop
content library: content that is created on the laptop is accessed through the Journal; preloaded content is stored in a library and is accessed through the Browse activity
bundle/activity bundle: a “zip” file with a .xo suffix used to package and distribute activities; bundles are installed in ~/Activities
content bundle/collection: a “zip” file with a .xol suffix used to package and distribute content; bundles are installed in ~/Library
roadmap: a plan made up of stages
sugar coat or sugar coating: A process for making Linux apps run under the Sugar desktop (i.e. making them to run in the Sugar interface, without the collaboration and other Sugar integration programmed into them).
sugarizing: A process of re-engineering Linux applications to run as native Sugar activities which take advantage of Sugar's collaboration capabilities and interface.

Documentation and Support

Wiki: a collaborative website that allows for community contributions and editing, e.g., http://wiki.sugarlabs.org
IRC/chat (Internet Relay Chat): real-time text chat used by the development and technical support communities (and hopefully the learning community as well)
email list: a collection of email addresses—an efficient way to send email to a group of people who share an interest

Localization

Pootle: a server that is used to store and manage translation templates and files
POT file: the master translation template for a project
PO file: a file containing the instance of translated strings for a single language based upon a POT file