34
edits
Changes
Jump to navigation
Jump to search
Line 20:
Line 20: − + − + Line 67:
Line 67: − + Line 165:
Line 165: − + Line 192:
Line 192: − +
no edit summary
;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:#e3e4e5;" |Journal Rethink ||valign=top width="15%" | Sam Parkinson<br>Ignacio Rodríguez ||align=left valign=top|
!valign=top | [[File:Journal-12.jpeg|90px|thumb|center]] ||valign=top width="15%" style="background:#e3e4e5;" |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.
;Knowledge prerequisite: Strong background in Python and knowledge of Gtk+.
;Knowledge prerequisite: Strong background in Python and knowledge of Gtk+.
|-
|-
!valign=top | [[Image:Sugarlabs_mainpage_01.png|90px|thumb|center]] ||valign=top width="15%" style="background:#e3e4e5;" | Groups Rethink ||valign=top width="15%" | Sam Parkinson<br>Ignacio Rodríguez ||align=left valign=top|
!valign=top | [[Image:Sugarlabs_mainpage_01.png|90px|thumb|center]] ||valign=top width="15%" style="background:#e3e4e5;" | Groups Rethink ||valign=top width="15%" | Sam Parkinson ||align=left valign=top|
;Brief explanation: Sugar has a buddies/group zoom view, which is very limited. It could be further integrated with sugar (eg. send to group, share with group, have a shared group journal) and expanded upon (having multiple groups user configured, like: a science prac group, a drama play group, etc.).
;Brief explanation: Sugar has a buddies/group zoom view, which is very limited. It could be further integrated with sugar (eg. send to group, share with group, have a shared group journal) and expanded upon (having multiple groups user configured, like: a science prac group, a drama play group, etc.).
;Expected results: Working code for the Sugar and vague ideas (more concrete than this) defined ahead of time.
;Expected results: Working code for the Sugar and vague ideas (more concrete than this) defined ahead of time.
|-
|-
!valign=top | ||valign=top width="15%" style="background:#e3e4e5;" | Covert Record, Clock, Speak and Measure to gstreamer 1.0 ||valign=top width="15%" | Ignacio Rodríguez ||align=left valign=top|
!valign=top | ||valign=top width="15%" style="background:#e3e4e5;" | Covert Record, Clock, Speak and Measure to gstreamer 1.0 ||valign=top width="15%" | <TBD> ||align=left valign=top|
;Brief explanation: The vast majority of Activities that use gstreamer for sound have been converted to gstreamer 1.0 because the older 0.10 is now End of Life and is no longer being developed. It also adds quite a large set of extra duplicate dependencies to Sugar distributions. There's a lot of good examples of Activities that have been converted to provide excellent examples. The gstreamer 1.0 bindings are provided by gobject-introspection so it also assists in the conversion of Activities to gtk3.
;Brief explanation: The vast majority of Activities that use gstreamer for sound have been converted to gstreamer 1.0 because the older 0.10 is now End of Life and is no longer being developed. It also adds quite a large set of extra duplicate dependencies to Sugar distributions. There's a lot of good examples of Activities that have been converted to provide excellent examples. The gstreamer 1.0 bindings are provided by gobject-introspection so it also assists in the conversion of Activities to gtk3.
;Expected results: As many of the above Activities converted to use gst 1.0
;Expected results: As many of the above Activities converted to use gst 1.0
|-
|-
!valign=top | [[File:Journal.png|90px|thumb|center]] ||valign=top width="15%" style="background:#e3e4e5;" | Sugar Journal backup and restore ||valign=top width="15%" | Tony Anderson<br>Ignacio Rodriguez||align=left valign=top|
!valign=top | [[File:Journal.png|90px|thumb|center]] ||valign=top width="15%" style="background:#e3e4e5;" | 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
|-
|-
!valign=top | [[File:Journal.png|90px|thumb|center]] ||valign=top width="15%" style="background:#e3e4e5;" | Sugar Activity resume feature ||valign=top width="15%" | Tony Anderson<br>Ignacio Rodriguez ||align=left valign=top|
!valign=top | [[File:Journal.png|90px|thumb|center]] ||valign=top width="15%" style="background:#e3e4e5;" | Sugar Activity resume feature ||valign=top width="15%" | Tony Anderson ||align=left valign=top|
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 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).