Changes

finish #sugar excerpts, add link to gnome thread
Line 26: Line 26:  
:<nowiki>[</nowiki>xdelta for binary diffs]
 
:<nowiki>[</nowiki>xdelta for binary diffs]
 
:<nowiki>[</nowiki>in-place execution of activities from datastore]
 
:<nowiki>[</nowiki>in-place execution of activities from datastore]
 +
:"Running an activity" is a special system-level action available on objects of type "Activity". It specifically means "Executing the code in activity object X with a null input". The other action is "Open with {some activity}".
 +
:another possibility is to ignore branches, and have each leaf ("head") simply show all of its ancestors as a list.
 +
:The Actions view shows "a temporal view of what I did", and the Objects view shows "what I have".
    
;tomeu:
 
;tomeu:
 
:<nowiki>[</nowiki>opportunistic hardlinking using mtime+checksum]
 
:<nowiki>[</nowiki>opportunistic hardlinking using mtime+checksum]
 +
:all activities should be able to read all journal instances written by past versions, but we cannot expect it will be that way
    
;silbe:
 
;silbe:
 
:<nowiki>[</nowiki>filenames are just metadata]
 
:<nowiki>[</nowiki>filenames are just metadata]
 +
:what about resuming old entries then? does it "run" the activity version it was created in?
 +
:we could filter "temporally near" versions in the default view.
 +
:instead of / in addition to the version tree view, we could have a filter that shows only the "related" (i.e. member of same version tree) documents in the regular Journal view
 +
:<nowiki>[</nowiki>actions view out of scope]
    
;homunq:
 
;homunq:
 
:<nowiki>[</nowiki>evaluate bazaar etc. as backend] -- SS: potential conflict with XIP - though git might be fine
 
:<nowiki>[</nowiki>evaluate bazaar etc. as backend] -- SS: potential conflict with XIP - though git might be fine
 +
:<nowiki>[</nowiki>run activities directly from zip file]
 +
:In the main journal list, you can have old versions in the palette, much like the new resume-by-default behaviour in current home view. In journal details, I guess you could have "previous" and "next" buttons as the simple first pass, I'd like a list of versions even better.
 +
:I'd argue that showing separate versions separately in journal list will never be the right thing. I'd rather have ALL old versions totally invisible in journal list (only accessible through "prev/next version" buttons in detail view) than have anything.
 +
:<nowiki>[</nowiki>in response to current Journal being temporal view, so intermediate versions should be there] OK, but they should be grouped, and collapsed by default, to show just head
 +
:I think the simplest, usable prototype would be what I said: just head in list, prev/next buttons in details.
 +
:for now, I'd accept tags as either by-version or global, but mutable and not versioned themselves
 +
:it's really a question of UIs and workflows, and having the prototype will help us actually test some workflows and get a more-informed conversation
 +
 +
=== Gnome work ===
 +
 +
[http://mail.gnome.org/archives/desktop-devel-list/2009-April/msg00004.html first part] and
 +
[http://mail.gnome.org/archives/desktop-devel-list/2009-April/msg00005.html second part] of Roadmap mail.
344

edits