Changes

Line 33: Line 33:     
=== Core Software ===
 
=== Core Software ===
 +
==== Versioned Datastore ====
 +
 +
* To add [[DevelopmentTeam/DatastoreRewrite#Versioned_entries_.28not_fulfilled_yet.29|Version support]] for [[Journal]] / [[DevelopmentTeam/Almanac/sugar.datastore.datastore|DataStore]]: Start with (old) [http://wiki.laptop.org/go/Olpcfs Olpcfs] and (newer; less-documented; based on an RCS backend and a relatively small amount of fuse magic) [http://dev.laptop.org/git/users/cscott/olpcfs2/ olpcfs2]. Get Sugar to mount OLPCFS2, a working virtual versioned filesystem, and keep its datastore there. Get datastore to create a new version for each save (automatic or manual). Modify journal UI to use these versions, fork from old versions, etc. Keep with the same name / tags, create a branch if metadata was changed. Allow the user to access "older" versions (Keeping and "old" version will create a branch) and view ancestry (tree of branches).
 +
 +
We would not expect a GSoC project to be necessarily ready to check into our trunk. For instance, you could avoid facing the issue of pruning old versions for disk space, or not have a converter for existing datastores. However, it should work as a proof-of-concept with a variety of activities.
 +
 +
*Priority for Sugar: High
 +
 +
*Coolness factor:++
 +
 +
*Difficulty: Hard
 +
 +
*Skills needed: primarily Python UI (pygtk); also FUSE/file systems (this part is mostly done); and Packaging and building.
 +
 +
====Implement existing UI design proposal====
 +
Look at [[Design_Team/Designs]] and [[Design_Team/Vision/Proposals]], choose a proposal in one of those, and implement it. Obviously, you need to investigate existing work on these by testing/playing with a current jhbuild and by talking on #sugar.
 +
 +
*Priority for Sugar: Medium
 +
 +
*Difficulty: easy-medium
 +
 +
*Skills needed: Python, PyGTK
 +
 
==== Registry for people ====
 
==== Registry for people ====
 
Extend the interaction model to include real people beyond the user–laptop couple. This would extend the virtual network to include some very significant entities, such as family members, who may not have a physical computing device. See the [[Request_New_Features#Support for family interaction | suggestion]] submitted by [[User:Skua]]. The [[olpc:Record]] Activity could be used as a fun, instance-of-person creator and embellisher, by capturing an image or video of the person, and linking it to a new registry.
 
Extend the interaction model to include real people beyond the user–laptop couple. This would extend the virtual network to include some very significant entities, such as family members, who may not have a physical computing device. See the [[Request_New_Features#Support for family interaction | suggestion]] submitted by [[User:Skua]]. The [[olpc:Record]] Activity could be used as a fun, instance-of-person creator and embellisher, by capturing an image or video of the person, and linking it to a new registry.
Line 86: Line 109:     
*Skills needed: intermediate GTK and python skillz
 
*Skills needed: intermediate GTK and python skillz
  −
==== Versioned Datastore ====
  −
  −
* To add [[DevelopmentTeam/DatastoreRewrite#Versioned_entries_.28not_fulfilled_yet.29|Version support]] for [[Journal]] / [[DevelopmentTeam/Almanac/sugar.datastore.datastore|DataStore]]: Start with (old) [http://wiki.laptop.org/go/Olpcfs Olpcfs] and (newer; less-documented; based on an RCS backend and a relatively small amount of fuse magic) [http://dev.laptop.org/git/users/cscott/olpcfs2/ olpcfs2]. Get Sugar to mount OLPCFS2, a working virtual versioned filesystem, and keep its datastore there. Get datastore to create a new version for each save (automatic or manual). Modify journal UI to use these versions, fork from old versions, etc. Keep with the same name / tags, create a branch if metadata was changed. Allow the user to access "older" versions (Keeping and "old" version will create a branch) and view ancestry (tree of branches).
  −
  −
We would not expect a GSoC project to be necessarily ready to check into our trunk. For instance, you could avoid facing the issue of pruning old versions for disk space, or not have a converter for existing datastores. However, it should work as a proof-of-concept with a variety of activities.
  −
  −
*Priority for Sugar: High
  −
  −
*Coolness factor:++
  −
  −
*Difficulty: Hard
  −
  −
*Skills needed: primarily Python UI (pygtk); also FUSE/file systems (this part is mostly done); and Packaging and building.
  −
  −
====Implement existing UI design proposal====
  −
Look at [[Design_Team/Designs]] and [[Design_Team/Vision/Proposals]], choose a proposal in one of those, and implement it. Obviously, you need to investigate existing work on these by testing/playing with a current jhbuild and by talking on #sugar.
  −
  −
*Priority for Sugar: Medium
  −
  −
*Difficulty: easy-medium
  −
  −
*Skills needed: Python, PyGTK
      
=== Toolkits / Frameworks for developers ===
 
=== Toolkits / Frameworks for developers ===
273

edits