Difference between revisions of "Summer of Code/2016"
(26 intermediate revisions by 6 users not shown) | |||
Line 1: | Line 1: | ||
'''Students''': See our guide on [[Summer_of_Code#How_to_participate|how to participate in Google Summer of Code]] for more information. | '''Students''': See our guide on [[Summer_of_Code#How_to_participate|how to participate in Google Summer of Code]] for more information. | ||
+ | |||
+ | The Sugar Labs Google Summer of Code 2016 projects/students/mentors: | ||
+ | {| border=1 cellpadding=3 style="border: 1px solid white; border-collapse: collapse; background: #e3e4e5;" | ||
+ | |-style="background:#787878; color: white;" | ||
+ | ! Project !! Student !! Mentors !! Proposal !! Blog !! IRC nick | ||
+ | |- | ||
+ | |Font Editor Activity||Yash Agarwal||Dave Crossland, Eli Heuer || [https://sugarlabs.github.io/edit-fonts-activity/refined-proposal] || [http://sugarlabs.github.io/font-editor-activity/] || yagarwal | ||
+ | |- | ||
+ | |Git Backend||Vikram Ahuja||Walter Bender, Tymon Radzik || Pending || [http://vikramahujagsoc.blogspot.com/] || vikram | ||
+ | |- | ||
+ | |Journal Rethink||Abhijit Patel||Walter Bender, Sam Parkinson||[https://www.docdroid.net/hbalTLC/1458885012-journal-rethink-proposal.pdf.html] || [http://abrahmab.github.io/] || AbrahmAB | ||
+ | |- | ||
+ | |Music Widgets||Hemant Kasat||Walter Bender, Devin Ulibarri || Pending || [http://musicblocks.net/2016/06/13/multiple-rhythm-rulers/] || hemant_kasat | ||
+ | |- | ||
+ | |Sugarizer OS||Jeremie Amsellem||Lionel Laské, Michaël Ohayon || Pending || [http://lp1-eu.blogspot.fr/] || lp1 | ||
+ | |- | ||
+ | |Sugar on the Ground||Utkarsh Tiwari||Tony Anderson, Sebastian Silva || [http://docdro.id/zx9U1Vd] || [https://iamutkarshtiwari.wordpress.com/about/google-summer-of-code16-with-sugar-labs-2/] || iamutkarshtiwari | ||
+ | |} | ||
== Project candidates == | == Project candidates == | ||
Line 8: | Line 26: | ||
;Note 1: Potential mentors, please feel free to add ideas to this list. Also, feel free to add your name to a project you'd be willing to co-mentor. | ;Note 1: Potential mentors, please feel free to add ideas to this list. Also, feel free to add your name to a project you'd be willing to co-mentor. | ||
;Note 2: Potential students, more project ideas can be found on our [[Features]] page. | ;Note 2: Potential students, more project ideas can be found on our [[Features]] page. | ||
+ | ;Note 3: Accepted projects are in <font color="#00bb00">Green</font> | ||
== Sugar Core == | == Sugar Core == | ||
Line 20: | Line 39: | ||
;Knowledge prerequisites: Some knowledge of Pootle; some scripting experience; Python | ;Knowledge prerequisites: Some knowledge of Pootle; some scripting experience; Python | ||
|- | |- | ||
− | !valign=top | [[File:Journal-12.jpeg|90px|thumb|center]] ||valign=top width="15%" style="background:# | + | !valign=top | [[File:Journal-12.jpeg|90px|thumb|center]] ||valign=top width="15%" style="background:#00bb00;" |Journal Rethink ||valign=top width="15%" | Sam Parkinson ||align=left valign=top| |
;Brief explanation: The Sugar Journal could be rethought to add more emphasis on collaboration, or adding more organisational support for creating "projects" among other things. | ;Brief explanation: The Sugar Journal could be rethought to add more emphasis on collaboration, or adding more organisational support for creating "projects" among other things. | ||
;Expected results: Working code for the journal and vague ideas (more concrete than this) defined ahead of time. | ;Expected results: Working code for the journal and vague ideas (more concrete than this) defined ahead of time. | ||
Line 37: | Line 56: | ||
|- | |- | ||
− | !valign=top | [[File:git_logo.png|90px|thumb|center]] ||valign=top width="15%" style="background:# | + | !valign=top | [[File:git_logo.png|90px|thumb|center]] ||valign=top width="15%" style="background:#00bb00;" |Git backend||valign=top width="15%" | Martin Abente Lahaye and Walter Bender ||align=left valign=top| |
;Brief explanation: The Sugar Journal doesn't do a great job of supporting versioning or forking. This project is to build a backend for the Journal that is based on git, which does support versioning and forking. By building on top of a git hosting site we get the added benefit of network access as well. | ;Brief explanation: The Sugar Journal doesn't do a great job of supporting versioning or forking. This project is to build a backend for the Journal that is based on git, which does support versioning and forking. By building on top of a git hosting site we get the added benefit of network access as well. | ||
;Expected results: Working code and an integration with Turtle Blocks | ;Expected results: Working code and an integration with Turtle Blocks | ||
Line 58: | Line 77: | ||
;Expected results: Improved user experience for users of regular Linux apps, merged to Sugar mainline. | ;Expected results: Improved user experience for users of regular Linux apps, merged to Sugar mainline. | ||
;Knowledge prerequisite: Strong background in GTK, Python and GNU/Linux. | ;Knowledge prerequisite: Strong background in GTK, Python and GNU/Linux. | ||
+ | |||
+ | |- | ||
+ | !valign=top | [[File:html5_logo.png|90px|thumb|center]] ||valign=top width="15%" style="background:#e3e4e5;" |Port Sugar to the Broadwayd HTML5 GTK Backend||valign=top width="15%" | [[User:Sebastian|Sebastian]] ([[User talk:Sebastian|talk]]) 14:09, 10 March 2016 (EST) ||align=left valign=top| | ||
+ | ;Brief explanation: Sugar uses GTK3. Recently GTK3 released support for a HTML5 native backend called Broadwayd. | ||
+ | ;Expected results: Make it feasible to run Sugar and pure gtk3 activities thru a browser (not Sugarizer). Docker container for Sugar on Broadwayd. | ||
+ | ;Knowledge prerequisite: Strong background in GTK, Python and GNU/Linux. Docker. | ||
|} | |} | ||
Line 86: | Line 111: | ||
|- | |- | ||
− | !valign=top | [[File:Music-Blocks.png|90px|thumb|center]] ||valign=top width="15%" style="background:# | + | !valign=top | [[File:Music-Blocks.png|90px|thumb|center]] ||valign=top width="15%" style="background:#00bb00" | Music Widgets||valign=top width="15%" | Devin Ulibarri ||align=left valign=top| |
;Brief explanation: Development four new widgets to improve the possibilities for music | ;Brief explanation: Development four new widgets to improve the possibilities for music | ||
learning as well as overall user-experience for Music Blocks. The widgets are 1. Pitch-Staircase 2. Tempo 3. Rhythm Rulers, and 4. Free-Pitch Slider. Widgets will integrate with the current coding environment without disrupting the underlying language in any way (like the current pitch-time matrix). | learning as well as overall user-experience for Music Blocks. The widgets are 1. Pitch-Staircase 2. Tempo 3. Rhythm Rulers, and 4. Free-Pitch Slider. Widgets will integrate with the current coding environment without disrupting the underlying language in any way (like the current pitch-time matrix). | ||
;Expected results: Users will use these to explore musical concepts and generate desired | ;Expected results: Users will use these to explore musical concepts and generate desired | ||
blocks from their experiments. | blocks from their experiments. | ||
− | ;Knowledge prerequisite: Strong background in | + | ;Knowledge prerequisite: Strong background in JavaScript, Basic knowledge of Music Theory |
and/or physics | and/or physics | ||
+ | |||
+ | |- | ||
+ | !valign=top | || valign=top width = "15%" style="background:#00bb00;" | [[Font Editor|Font Editor Activity]]||valign=top width="15%" | with Dave Crossland || align=left valign=top| | ||
+ | ;Brief explanation: Typeface design is a cornerstone of literate cultures, with subliminal power: Typefaces carry the emotions of texts, from formal designs that speak with authority to fun designs that are silly or military or ornate. They are both artistic and functional works, and our ability to share and modify them is important for the same reasons as for software programs. A Sugar font editor activity will empower users to create and modify fonts for their own tastes and needs. Fonts are fun to make, but we need an editor to do it. | ||
+ | |||
+ | ;Expected results: Lots of free software Python and JavaScript libraries already exist so this project offers the possibility to make real progress for users this summer. | ||
+ | ;Knowledge prerequisite: Strong background in JavaScript or Python | ||
+ | : | ||
+ | : | ||
|} | |} | ||
Line 159: | Line 193: | ||
|- | |- | ||
− | !valign=top | [[File:Journal.png|90px|thumb|center]] ||valign=top width="15%" style="background:# | + | !valign=top | [[File:Journal.png|90px|thumb|center]] ||valign=top width="15%" style="background:#00bb00;" | Sugar Journal save option ||valign=top width="15%" | Tony Anderson ||align=left valign=top| |
The Sugar Journal should provide a 'save/save as' interface which should enable a user to choose whether to save the current document when an activity is closed. The interface should require a name change from 'current.activity' to a user supplied name. If the document is derived from one currently saved in the Journal, the user should be allowed to save (overwrite) or save as (create new document) by giving a new name to the document. This could be accomplished by showing a modal dialog at close time requesting the user to supply a name or not save the document. If the document has a user supplied name, the dialog could request the user to save or to provide a new name to create a new document. | The Sugar Journal should provide a 'save/save as' interface which should enable a user to choose whether to save the current document when an activity is closed. The interface should require a name change from 'current.activity' to a user supplied name. If the document is derived from one currently saved in the Journal, the user should be allowed to save (overwrite) or save as (create new document) by giving a new name to the document. This could be accomplished by showing a modal dialog at close time requesting the user to supply a name or not save the document. If the document has a user supplied name, the dialog could request the user to save or to provide a new name to create a new document. | ||
Line 172: | Line 206: | ||
|- | |- | ||
− | !valign=top | [[File:Journal.png|90px|thumb|center]] ||valign=top width="15%" style="background:# | + | !valign=top | [[File:Journal.png|90px|thumb|center]] ||valign=top width="15%" style="background:#00bb00;" | Sugar Journal backup and restore ||valign=top width="15%" | Tony Anderson ||align=left valign=top| |
Sugar provides a method to backup and restore the Journal (one method to a USB key and one method to the school server). The Journal also provides a select box to enable an action to be taken for all selected objects. This mechanism should be sufficient for the USB key case. However, the school server backup currently is based on taking a snapshot of the current Journal state. This means the size of the objects in a user's Journal cannot exceed the available local store on an XO (300MB for an XO-1, 1.9GB for other models). A mechanism is needed to save on the school server all documents created by the user and to restore a selected object to the Journal from the school server. Since many documents may represent library objects (e-books, audio, image or video media), the mechanism should recognize these and not save them as user documents. However, the metadata saved should enable the system to download the library items again as needed (and, as available). | Sugar provides a method to backup and restore the Journal (one method to a USB key and one method to the school server). The Journal also provides a select box to enable an action to be taken for all selected objects. This mechanism should be sufficient for the USB key case. However, the school server backup currently is based on taking a snapshot of the current Journal state. This means the size of the objects in a user's Journal cannot exceed the available local store on an XO (300MB for an XO-1, 1.9GB for other models). A mechanism is needed to save on the school server all documents created by the user and to restore a selected object to the Journal from the school server. Since many documents may represent library objects (e-books, audio, image or video media), the mechanism should recognize these and not save them as user documents. However, the metadata saved should enable the system to download the library items again as needed (and, as available). | ||
;For example: the mechanism may be to upload Journal documents to an OwnCloud repository. The user could then select an item in the OwnCloud repository to be downloaded to the Journal. The user could also share any item in OwnCloud with other user groups or individuals | ;For example: the mechanism may be to upload Journal documents to an OwnCloud repository. The user could then select an item in the OwnCloud repository to be downloaded to the Journal. The user could also share any item in OwnCloud with other user groups or individuals | ||
Line 192: | Line 226: | ||
|- | |- | ||
− | !valign=top | [[File:Journal.png|90px|thumb|center]] ||valign=top width="15%" style="background:# | + | !valign=top | [[File:Journal.png|90px|thumb|center]] ||valign=top width="15%" style="background:#00bb00;" | Sugar Journal activity resume feature ||valign=top width="15%" | Tony Anderson ||align=left valign=top| |
In Sugar's Home View, a click on an activity icon by default resumes the most recent instance of the activity. This capability is designed into the Journal and is redundant in the Home View. A Sugar activity is a tool to enable the user to accomplish some task. If that task is not completed, the user can resume it via the Journal. If the tool is to be used on a new task, the user can launch it from the Home View. The current Home View assumes that the intent of the user is to continue the most recent task with that tool. | In Sugar's Home View, a click on an activity icon by default resumes the most recent instance of the activity. This capability is designed into the Journal and is redundant in the Home View. A Sugar activity is a tool to enable the user to accomplish some task. If that task is not completed, the user can resume it via the Journal. If the tool is to be used on a new task, the user can launch it from the Home View. The current Home View assumes that the intent of the user is to continue the most recent task with that tool. | ||
Line 205: | Line 239: | ||
|- | |- | ||
− | !valign=top | [[File:Journal.png|90px|thumb|center]] ||valign=top width="15%" style="background:# | + | !valign=top | [[File:Journal.png|90px|thumb|center]] ||valign=top width="15%" style="background:#00bb00;" | Sugar offline ||valign=top width="15%" | Tony Anderson ||align=left valign=top| |
There are a number of Sugar activities which currently require access to the internet (InfoSlicer, GetBooks). These activities should have an option to function with the school server. For example, GetBooks could access books on the school server and InfoSlicer could create slices from Wikipedia on the school server as Journal objects. | There are a number of Sugar activities which currently require access to the internet (InfoSlicer, GetBooks). These activities should have an option to function with the school server. For example, GetBooks could access books on the school server and InfoSlicer could create slices from Wikipedia on the school server as Journal objects. | ||
Line 240: | Line 274: | ||
|- | |- | ||
− | !valign=top | [[File:Sugarizer os android.png|90px|thumb|center]] ||valign=top width="15%" style="background:# | + | !valign=top | [[File:Sugarizer os android.png|90px|thumb|center]] ||valign=top width="15%" style="background:#00bb00;" | Sugarizer OS ||valign=top width="15%" | Lionel Laské and Michaël Ohayon||align=left valign=top| |
The goal of this project is to create "Sugarizer OS". | The goal of this project is to create "Sugarizer OS". | ||
Sugarizer OS is a way to boot directly a device on Sugarizer and allow the user to use both Sugarizer activities and system native applications. Sugarizer OS is not an OS but a way to propose a full Sugar experience on a non-Sugar device. | Sugarizer OS is a way to boot directly a device on Sugarizer and allow the user to use both Sugarizer activities and system native applications. Sugarizer OS is not an OS but a way to propose a full Sugar experience on a non-Sugar device. |
Latest revision as of 14:01, 6 October 2016
Students: See our guide on how to participate in Google Summer of Code for more information.
The Sugar Labs Google Summer of Code 2016 projects/students/mentors:
Project | Student | Mentors | Proposal | Blog | IRC nick |
---|---|---|---|---|---|
Font Editor Activity | Yash Agarwal | Dave Crossland, Eli Heuer | [1] | [2] | yagarwal |
Git Backend | Vikram Ahuja | Walter Bender, Tymon Radzik | Pending | [3] | vikram |
Journal Rethink | Abhijit Patel | Walter Bender, Sam Parkinson | [4] | [5] | AbrahmAB |
Music Widgets | Hemant Kasat | Walter Bender, Devin Ulibarri | Pending | [6] | hemant_kasat |
Sugarizer OS | Jeremie Amsellem | Lionel Laské, Michaël Ohayon | Pending | [7] | lp1 |
Sugar on the Ground | Utkarsh Tiwari | Tony Anderson, Sebastian Silva | [8] | [9] | iamutkarshtiwari |
Project candidates
In the table below is a list of projects potential participants might contribute to in the GSoC program.
- Note 0
- These are project ideas from Sugar Labs contributors. Students, feel free to propose your ideas as well.
- Note 1
- Potential mentors, please feel free to add ideas to this list. Also, feel free to add your name to a project you'd be willing to co-mentor.
- Note 2
- Potential students, more project ideas can be found on our Features page.
- Note 3
- Accepted projects are in Green
Sugar Core
Title | Mentor | Project | |
---|---|---|---|
Internationalization and Localization | Chris Leonard |
| |
Journal Rethink | Sam Parkinson |
| |
Groups Rethink | Sam Parkinson |
| |
Reflect Activity | Sam Parkinson and Walter Bender |
| |
Git backend | Martin Abente Lahaye and Walter Bender |
| |
Performance tuning on machines with limited memory | Samuel Greenfeld |
| |
Re-design collaboration with web technologies | Martin Abente Lahaye and Walter Bender |
| |
Make Sugar compliant with Freedesktop standards | Sebastian (talk) 13:50, 10 March 2016 (EST) |
| |
Port Sugar to the Broadwayd HTML5 GTK Backend | Sebastian (talk) 14:09, 10 March 2016 (EST) |
|
Sugar Activities
Title | Mentor | Project | |
---|---|---|---|
Beyond Flashcards: Programming to ReadJS | Walter Bender |
| |
Covert Record, Clock, Speak and Measure to gstreamer 1.0 | <TBD> |
| |
Covert TamTam to Csound6 | <TBD> |
| |
Music Widgets | Devin Ulibarri |
learning as well as overall user-experience for Music Blocks. The widgets are 1. Pitch-Staircase 2. Tempo 3. Rhythm Rulers, and 4. Free-Pitch Slider. Widgets will integrate with the current coding environment without disrupting the underlying language in any way (like the current pitch-time matrix).
blocks from their experiments.
and/or physics | |
Font Editor Activity | with Dave Crossland |
|
Sugar Activities (and Ports)
These are existing and new activities we'd like to see enhanced. We expect that the activities will take on new UI features and pedagogical significance.
Title | Mentor | Project | |
---|---|---|---|
Music Blocks Challenges | Devin Ulibarri |
| |
Nutritional Microworld | w/Dr. Jessica Early |
relevant tool—one that invites learners to explore fundamental concepts of nutrition that are both intrinsic to nutrition yet transcendent of a specific discipline.
| |
Turtle Confusion/Flags JS | Walter Bender |
| |
Tux Math | Tony Anderson |
The TuxMath activity is popular with deployments. However, the upstream version appears to be abandoned. This task would be to implement a sugar-web-activity math game comparable to TuxMath.
|
Sugar Technology
Sugar is based on the Python programming language and the GTK libraries. We also support some web technologies: HTML5, CSS, and JavaScript.
Title | Mentor | Project | |
---|---|---|---|
Unit Testing | TBD |
Deep dive into unit tests. We have a framework but it provides scant coverage for Sugar core and almost no coverage for Sugar activities.
| |
Redesign and recreate Sugar Labs webappearance | Tymon Radzik |
Create new modern and innovative design template for our websites and apply it to all our systems. Consider, how to improve our webappearance. Currently, almost every our website looks different than other and is created in different technology.
|
Sugar on the Ground
A number of real-world issues crop up in deployments of Sugar, especially where resources are limited (bandwidth, CPU speed, battery life, local storage, etc.) These tasks are related to making Sugar more usable under such circumstances.
Title | Mentor | Project | |
---|---|---|---|
Sugar Journal save option | Tony Anderson |
The Sugar Journal should provide a 'save/save as' interface which should enable a user to choose whether to save the current document when an activity is closed. The interface should require a name change from 'current.activity' to a user supplied name. If the document is derived from one currently saved in the Journal, the user should be allowed to save (overwrite) or save as (create new document) by giving a new name to the document. This could be accomplished by showing a modal dialog at close time requesting the user to supply a name or not save the document. If the document has a user supplied name, the dialog could request the user to save or to provide a new name to create a new document.
| |
Sugar Journal as a service | Tony Anderson |
The Journal activity is currently implemented as an activity. It should be changed to a 'service'. This means the Journal icon on the frame should be to the left of the zoom group icons to match the sequence on the keyboard. The Journal is always running as a service when the Sugar is running. It is accessible by the Journal key on the keyboard and also by the Journal button in the frame. When the view is switched to the Journal, clicking on the activity view (right most key of the zoom group) should switch the screen back to the current activity.
| |
Sugar Journal backup and restore | Tony Anderson |
Sugar provides a method to backup and restore the Journal (one method to a USB key and one method to the school server). The Journal also provides a select box to enable an action to be taken for all selected objects. This mechanism should be sufficient for the USB key case. However, the school server backup currently is based on taking a snapshot of the current Journal state. This means the size of the objects in a user's Journal cannot exceed the available local store on an XO (300MB for an XO-1, 1.9GB for other models). A mechanism is needed to save on the school server all documents created by the user and to restore a selected object to the Journal from the school server. Since many documents may represent library objects (e-books, audio, image or video media), the mechanism should recognize these and not save them as user documents. However, the metadata saved should enable the system to download the library items again as needed (and, as available).
| |
Sugar Journal session data management | Tony Anderson |
One goal of Sugar is to record information about user sessions. This is currently accomplished by creating statistics from the metadata stored in the Journal. Unfortunately, a consequence is that the Journal view fills with essentially meaningless links to this metadata (mine fills with Terminal Activity and Log entries). This makes it much harder for the user to identify meaningful Journal objects (documents, images, items from the library, ...). A mechanism is needed to that session data can be logged independently of the Journal view (i.e not shown on the screen). This logged information should be transferred to a backup repository (e.g. school server or USB drive) as soon as possible and deleted from the local store to free up space. The available reporting activities should be modified to use this new mechanism.
| |
Sugar Journal quota management | Tony Anderson |
The Journal icon provides information the amount of free space in the user's store. if this amount is less than 50MB, a dialog is shown requiring the user to switch to the Journal view and claiming that the 'Journal is Full'. This message is, at best, misleading. The available storage can arise from several causes - the fact that an activities 'instance' store was not deleted, the space required by installed activities, or space required by data files in /home/olpc/Library, or data stored by activities in 'data', 'instance' or 'temp'. Currently, Sugar provides no guidance or help to enable a user to deal with this problem short of reflashing the image. The goal of this task is to provide a quota management system on storage with a way for the user (e.g. by a special Sugar activity) to analyze the usage of storage and to save by usb key or school server or cloud storage large or currently unneeded items and then delete them. The system should show the user the size of items and provide updates on how much storage has been made free by his/her actions.
| |
Sugar Journal activity resume feature | Tony Anderson |
In Sugar's Home View, a click on an activity icon by default resumes the most recent instance of the activity. This capability is designed into the Journal and is redundant in the Home View. A Sugar activity is a tool to enable the user to accomplish some task. If that task is not completed, the user can resume it via the Journal. If the tool is to be used on a new task, the user can launch it from the Home View. The current Home View assumes that the intent of the user is to continue the most recent task with that tool. This task should set the Home View default to launch a new instance of the activity. The Alt key should be set to enable resuming a selected instance of the activity. By serendipity, this also shows the Home View with black and white icons. Icons with color signifying a resumable instance use the colors associated with the laptop. Unfortunately many of these color combinations make the icon much more difficult to distinguish than the black and white version.
| |
Sugar Activity resume feature | Tony Anderson |
Sugar provides a 'web services' capability. However, these services are only available to an XO which has connection to the internet. This is not useful to a large number of users who do not have internet access. The school server (e.g. XSCE) provides an alternative to the internet for many deployments. This task is to provide a capability on the school server to support some or all of the Sugar web services (e.g. by OwnCloud or ELGG).
| |
Sugar offline | Tony Anderson |
There are a number of Sugar activities which currently require access to the internet (InfoSlicer, GetBooks). These activities should have an option to function with the school server. For example, GetBooks could access books on the school server and InfoSlicer could create slices from Wikipedia on the school server as Journal objects.
| |
Sugar "on-boarding" | Tony Anderson |
Sugar users are often new to computers and not familiar with other operating systems. We need a mechanism to allow users to more quickly develop skills in using the capabilities of the XO ('onboarding'). One proposal is to develop scripts which lead the user through a series of interactive steps illustrating common usage of the XO with Sugar ([10]). This task is to implement an interpretive system that allows deployments or experienced users to create an 'onboard' script that guides the user to carry out a task. The referenced proposal suggests some user tasks where this mechanism could be employed. Since there is no finite list of these tasks, an interpretive approach enables the scripts to be created as necessary.
| |
32bit Sugar on Ubuntu | Tony Anderson |
Sugar is available on the XO and some other platforms. In particular, Sugar is available for 64-bit systems with Ubuntu 14.04 LTS installed (http://wiki.sugarlabs.org/go/Ubuntu). Unfortunately, this procedure does not work with 32-bit systems. There exists an opportunity to deploy Sugar with relatively inexpensive or refurbished laptops which do not provide 64-bit support. This task is to create a comparable version of Sugar which can be installed on 32-bit systems as an alternate Ubuntu desktop.
| |
One to Many Sugar | Tony Anderson |
The OLPC model is that each user has full possession and is the only user of an XO laptop. Therefore, Sugar assumes a 1-1 correspondence between users and XO serial numbers. However, Sugar is being used on other platforms (e.g. SOAS), where there is no obvious equivalent to a serial number. SOAS and James Cameron [citation?] have created versions of Sugar which do not assume the user is 'olpc', but implement a standard username/password login system. The users storage is allocated to his/her home directory. This task is to create a Sugar image for the XO which allows for user's to login by username and password. The basic task is to move the Activities folder to a common space so that only one copy is needed per system. This will support deployments where one set of laptops are shared across multiple classes (and users) or where there one laptop is shared between two students - one in a morning shift and the other in an afternoon shift. |
Sugarizer
Sugarizer is a way to use Sugar on any device using web technologies (HTML5/JavaScript). Strictly speaking, Sugarizer is not a port of Sugar. Sugarizer is based on Sugar Web library, which mimics the Sugar UI using HTML5 and CSS3 and reproduces Sugar views (Home, List, ...). Sugarizer reimplements features of Sugar Core (datastore and journal) in JavaScript and integrates a bunch of activities written for Sugar in Sugar Web.
Title | Mentor | Project | |
---|---|---|---|
Sugarizer OS | Lionel Laské and Michaël Ohayon |
The goal of this project is to create "Sugarizer OS". Sugarizer OS is a way to boot directly a device on Sugarizer and allow the user to use both Sugarizer activities and system native applications. Sugarizer OS is not an OS but a way to propose a full Sugar experience on a non-Sugar device. On Android, Sugarizer OS will take the form of an Android Launcher so it will be able to replace the standard Android launcher of the device. So the user will be able to launch both Sugarizer Activities and Android application from the Sugarizer home. The Sugarizer List View screen will let you choose which Android application icons will appear in the favorite view. Into Sugarizer OS the Neighborhood view will let the user see and connect to a WiFi hotspot as in Sugar. The Sugarizer OS settings will allow to access to Android settings and let the use to switch to the standard Android launcher. Prerequisite: Android, Java, HTML5/JavaScript. How to start: Clone the Sugarizer repository, then create your own APK following instructions here. Think about how to adapt this APK to transform it into an Android launcher. | |
Sugarizer Server Dashboard | Lionel Laské and Michaël Ohayon |
The goal of this project is to create the "Sugarizer Server Dashboard". Sugarizer Server Dashboard is a web admin console for Sugarizer Server. The Dashboard will allow to manage and analyze all activity on a Sugarizer Server. Dashboard features will include:
Technology to use: HTML5/JavaScript, bootstrap, node.js, MongoDB How to start: Clone the Sugarizer repository, then install Sugarizer server using instructions here, finally explore the Sugarizer Server API and think about way to implement dashboard features.
| |
Sugarizer Activity Set | Lionel Laské and Michaël Ohayon |
The goal of this project is to port some famous Sugar activities into HTML5/JavaScript Sugar Web activities that will be include into the Sugarizer Package. Three activities will be ported:
Technology to use: HTML5/JavaScript How to start: Download and install Sugar like explain here and install the existing version of activities to port: Moon, Speak, Fototoon. Clone the Sugarizer repository, then create an empty Sugarizer activity following instructions here. Think about how to reproduce features of existing activities. |
Subpages
- Summer of Code/2016/BeyondFlashcardsProgrammingtoReadJS
- Summer of Code/2016/GitBackend
- Summer of Code/2016/Journal Rethink
- Summer of Code/2016/LearnForFun
- Summer of Code/2016/MusicWidgets and MusicBlocksChallenges
- Summer of Code/2016/Nutritional Microworld
- Summer of Code/2016/Redesign and recreate Sugar Labs webappearance
- Summer of Code/2016/Redesign and recreate sugarlabs web appearance
- Summer of Code/2016/Redesign and recreate suugarlabs web appearance
- Summer of Code/2016/SugarJournalSaveOption UtkarshT
- Summer of Code/2016/SugarLabs Websites Redesign
- Summer of Code/2016/Sugar Journal backup and restore
- Summer of Code/2016/SugarizerActivitySet
- Summer of Code/2016/SugarizerOS
- Summer of Code/2016/Sugarizer Activity Set
- Summer of Code/2016/Sugarizer OS
- Summer of Code/2016/Sugarizer Server Dashboard
- Summer of Code/2016/TeachingKidstoCode
- Summer of Code/2016/TurtleConfusion FlagJS
- Summer of Code/2016/Turtle Confusion/Flags JS
- Summer of Code/2016/beyondFlashCards