Changes

Jump to navigation Jump to search
update link for Google Doc
Line 7: Line 7:  
[[Image:journal-version-mockup-4.png|800px|thumb|left|Third mockup: combo box with Favourite stars (closed)]]
 
[[Image:journal-version-mockup-4.png|800px|thumb|left|Third mockup: combo box with Favourite stars (closed)]]
 
[[Image:journal-version-mockup-5.png|800px|thumb|left|Third mockup: combo box with Favourite stars (open)]]
 
[[Image:journal-version-mockup-5.png|800px|thumb|left|Third mockup: combo box with Favourite stars (open)]]
 
+
<br clear>
 
== Scratch area ==
 
== Scratch area ==
   Line 24: Line 24:  
:Basically, all versions of a document would appear within the list view timeline. Their order within the list would be determined by their timestamp. If I work on 3 iterative versions of a document, then go back to the second version and make changes, I get a new 4th version which appears as the most recent item in the Journal. It doesn't matter (at least here) that I technically have a branch at version 2, which has children 3 and 4. What matters in the Journal perspective is that I worked on version 4 most recently. The tree is flattened into a list in the time dimension.
 
:Basically, all versions of a document would appear within the list view timeline. Their order within the list would be determined by their timestamp. If I work on 3 iterative versions of a document, then go back to the second version and make changes, I get a new 4th version which appears as the most recent item in the Journal. It doesn't matter (at least here) that I technically have a branch at version 2, which has children 3 and 4. What matters in the Journal perspective is that I worked on version 4 most recently. The tree is flattened into a list in the time dimension.
 
:This is also the reason that the latest Journal designs split the UI into "action" and "object" views. The action view would be a temporal history of everything you've done (with each version through time). The object view would represent each object only once, by it's most recent version, thus providing a much shorter list.
 
:This is also the reason that the latest Journal designs split the UI into "action" and "object" views. The action view would be a temporal history of everything you've done (with each version through time). The object view would represent each object only once, by it's most recent version, thus providing a much shorter list.
 +
 +
;Eben & Tomeu:
 +
This thread, http://www.mail-archive.com/sugar-devel@lists.sugarlabs.org/msg06008.html, consolidated in context,
 +
 +
https://docs.google.com/Doc?docid=0AbFyRSVE0dmOZGQ5emZjOTZfMzBoeG1qMjhqbg&hl=en
 +
 +
sugarlabs.org Google Docs original:
 +
 +
https://docs.google.com/Doc?docid=0AUl2E5uTm959ZGd3N3FucXdfMWhzbjVjeGht&hl=en
    
=== IRC notes ===
 
=== IRC notes ===
Line 73: Line 82:  
= Datastore feature requests =
 
= Datastore feature requests =
   −
=== Features that could benefit Library activity ===
+
* [[Development_Team/Release/Roadmap/0.86#Datastore_features_that_could_benefit_Library]]
 
  −
These features can benefit [[Activities/Library]] activity. At present(for 0.82/0.84) Library uses "rich" datastore client which fetches all Journal objects to make short list of objects(by collapsing all versions to one item), moreover it has to unzip .xo bundles to get ''bundle_id'' value. So its not good.
  −
 
  −
With all these features implemented Library can use "thin" datastore client and not fetch all objects, just make proper request for datasotre.find() to get sorted and collapsed objects by portions (by using offset/limit find() arguments).
  −
 
  −
====== Provide object id field ======
  −
 
  −
That should mean that any datastore object should have "object id":
  −
* ''activity_id'' for objects that were generated by activities (already implemented)
  −
* ''bundle_id'' for .xo bundles in the Journal
  −
* ''uid'' for other objecets (already implemented)
  −
 
  −
====== History of collapsed object ======
  −
 
  −
Let datastore clients browse history of collapsed objects:
  −
* for ''activity_id'' objects - sort by timestamp (already impelemented)
  −
* for ''bundle_id'' objects - sort by ''activity_version''(or so) field
  −
 
  −
====== Sort find()'s resultset ======
  −
 
  −
Let datastore clients sort objects by any field(not only predefined like uid, activity_id etc).
 

Navigation menu