Jump to content

Supported systems/Technical considerations: Difference between revisions

From Sugar Labs
generalization of a Bernie memo to ASUS
 
KachachanC (talk | contribs)
No edit summary
 
(8 intermediate revisions by 7 users not shown)
Line 1: Line 1:
{{Outdated}}
<noinclude>{{ GoogleTrans-en | es =show | bg =show | zh-CN =show | zh-TW =show | hr =show | cs =show | da =show | nl =show | fi =show | fr =show | de =show | el =show | hi =show | it =show | ja =show | ko =show | no =show | pl =show | pt =show | ro =show | ru =show | sv =show }}</noinclude>
{{Stub}}{{TOCright}}
There are a number of technical considerations for providing Sugar support.
There are a number of technical considerations for providing Sugar support.


==INTEGRATION==
==Integration==


Sugar is designed to be started as desktop option
Sugar is designed to be started as a desktop option
alongside Gnome and KDE rather than a plain "start menu"
alongside Gnome and KDE rather than a plain "start menu"
application.  This means that we should consider a "switch
application.  This means that we should consider a "switch
desktop" function if it is a requirement to ship multiple environments.
desktop" function if it is a requirement to ship multiple environments.


==APPLICATIONS==
==Applications==


In order to provide a consistent environment,
In order to provide a consistent environment,
Line 20: Line 23:
a thin shell around Firefox's engine.
a thin shell around Firefox's engine.


==PACKAGING==
==[[Packaging Team|Packaging]]==


At this time, we have alpha-quality packages
At this time, we have alpha-quality packages
Line 26: Line 29:
require additional packaging work, especially for the
require additional packaging work, especially for the
networking features.  Packaging Sugar for other distributions would be
networking features.  Packaging Sugar for other distributions would be
done in collaboration; appropriate contacts within those communities would be necessary.
done in collaboration; see [[Packaging Team]], appropriate contacts within those communities are welcome to join.


==SOFTWARE STACKS==
==Software stacks==


Sugar is based on quite a different set
Sugar is based on quite a different set
Line 38: Line 41:
the footprint of Sugar should be reasonably small.
the footprint of Sugar should be reasonably small.


==VENDOR CUSTOMIZATIONS==
==Vendor customization==


Sugar is moving to become an upstream
Sugar is moving to become an upstream
Line 46: Line 49:
criteria.
criteria.


==ENGINEERING SUPPORT==
==Engineering support==


We are aware that Sugar still requires
We are aware that Sugar still requires
much more engineering work to polish the user interface,
much more engineering work to polish the user interface,
stabilize the codebase, and complete missing features.  Since
stabilize the codebase, and complete missing features.  Since
when we started the Sugarlabs project, we have already
we started the Sugar Labs, we have already
attracted a few fresh volunteers.  But we'd appreciate hardware
attracted fresh volunteers.  But we'd appreciate hardware
vendors (and others) assigning resources to work with us and make things happen
vendors (and others) assigning resources to work with us and make things happen
faster.
faster.


==COMMUNITY INVOLVEMENT==
==Community involvement==


We are in contact with several government
We are in contact with several government
Line 64: Line 67:
in this process.
in this process.


==CONTENT==
==Content==


We are also looking for localized open content. Industry partners
We are also looking for localized open content. Industry partners
might be able to help here.
might be able to help here.


==DESIGN PROPOSALS==
==Design proposals==


We'd appreciate feedback and marketing input
We'd appreciate feedback and marketing input
from hardware manufacturers (and others) to enhance our environment.
from hardware manufacturers (and others) to enhance our environment.
[[Category:developer]]

Latest revision as of 00:06, 19 December 2016

This article is a stub. You can help Sugar Labs by expanding it.

There are a number of technical considerations for providing Sugar support.

Integration

Sugar is designed to be started as a desktop option alongside Gnome and KDE rather than a plain "start menu" application. This means that we should consider a "switch desktop" function if it is a requirement to ship multiple environments.

Applications

In order to provide a consistent environment, Sugar activities need to implement a number of custom APIs to access documents and perform collaborative work over the network. There is some degree of interoperability with ordinary GNU/Linux applications (which needs improvement), but "sugarizing" software is really the only way to provide a nice user experience for little children. This doesn't imply duplicating all code: our Browse activity is really a thin shell around Firefox's engine.

Packaging

At this time, we have alpha-quality packages for Fedora, Debian and Ubuntu. Seamless integration would require additional packaging work, especially for the networking features. Packaging Sugar for other distributions would be done in collaboration; see Packaging Team, appropriate contacts within those communities are welcome to join.

Software stacks

Sugar is based on quite a different set of components than the native PC desktop. Most code is written in Python and uses Cairo and GTK as its UI library. However, we also have a few activities written in C++, Small Talk and even C#, using disparate software stacks. If you are already supporting GTK based applications, the footprint of Sugar should be reasonably small.

Vendor customization

Sugar is moving to become an upstream project with respect to hardware and software distributors. We are glad to accept vendor-specific contributions back in our codebase, subject to peer review and a general usefulness criteria.

Engineering support

We are aware that Sugar still requires much more engineering work to polish the user interface, stabilize the codebase, and complete missing features. Since we started the Sugar Labs, we have already attracted fresh volunteers. But we'd appreciate hardware vendors (and others) assigning resources to work with us and make things happen faster.

Community involvement

We are in contact with several government organizations and grassroots groups which adopt laptops for primary education. They might want to run pilots using a variety of hardware in their respective countries. We are happy to assist in this process.

Content

We are also looking for localized open content. Industry partners might be able to help here.

Design proposals

We'd appreciate feedback and marketing input from hardware manufacturers (and others) to enhance our environment.