Hi Eric
----- Original message -----
> Unfortunately I haven't coded anything since our chat a few months ago
> :-(. I'm still thinking about how to build an editor with persistent
> undo/redo including actions like selection changes or revision control
> operations like revert or merge.
I had some thoughts about how to make this work. The main idea is to introduce
a concept of branches or branch pointers, where we not only store the history
of the object, but also the linear undo/redo history of the branch pointer.
Each time the user makes a change, we update the branch pointer and we also
create an undo history node of the change we made to the branch pointer in a
sort of branch history. Views then point to a branch pointer, and not to an
object. Importantly, views do not have history (they are merely
persisted/restored).
Things like selections are handled by storing them in the branch pointer
history, not in the object or view. This way, multiple views of the same object
can exist with different selections in each. Selections can then be undone.
Multiple views pointing to the same branch would have the same branch history.
Cloning an object would involve creating a new branch with the first history
node pointing to the same revision of the object.
I don't know anything about Quentin's history track idea, so this could be the
same thing.
> > When the persistent root is a compound document, a photo group etc.
> > explicit sharing can be expected. iirc To ensure a predictable and
> > stable behavior from the user's perspective, iirc we concluded that
> > embedded objects must be copied (even if it's a move) when inserted
> > into another persistent root, unlike root object which are just
> > aliased (through the UUID).
>
> I think that sounds good.. but I'm not totally sure.
>
> If you consider photos, I think the design used with iPhoto is good -
> within the library, photos are aliased/shared when you move them around,
> create groups, etc., but if you import or export from the library, a
> copy is created. Maybe if we wanted to emulate that, we would just make
> the library a persistent root, and the photos would be embedded objects.
>
> One potential problem is if we have multiple libraries containing
> composite documents containing images, and maybe we want the images to
> be copied if they're moved to a different document. The original design
> I was using for ObjectMerging with no notion of persistent root /
> embedded object would be able to handle this, by using an algorithm
> like: 1. find the closest parent of the drag source which is a document
> 2. find the closest parent of the drag destination which is a document
> 3. if the documents found in 1) and 2) are the same, link, otherwise,
> copy.
>
>
> On a semi-related topic, I think it should be possible to make deep
> copies in CoreObject really cheap - even if there are multiple GB's of
> image/video/music data inside the objects - we just need to make sure to
> share the attached files.
On both this point and Quentin's comment about one root object per context -
the idea was that you only operate on one root object per context, and any
others you introduce are just stored as links and not incorporated into that
object's history. I think this is sensible unless you want to version a set of
root objects together, although I don't think we want this as it makes undo
awkward if someone works on that object separately.
I agree that copying an object between libraries clones it, and copying it
within a library just makes a link. However, we could possibly inplement a
primitive sharing/backup mechanism by propagating revisions of the same object
between repositories.
Cheers
Chris
_______________________________________________
Etoile-dev mailing list
[email protected]
https://mail.gna.org/listinfo/etoile-dev
