Hey Quentin, >>> I've put together some patches for ObjectMerging4 that: >>> 1) Add makefiles for GNUstep >>> 2) Fix compilation errors >>> 3) Add primitive value persistence >>> >>> Please find them attached at: https://gna.org/patch/index.php?2652 > > Can I apply these patches to you branch? I'd like to start hacking on the > compound document editor soon.
Sure, feel free to commit to my branch. 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. >> Last week I chatted with Quentin and we settled a few things: >> >> - the undo/redo stack/tree must be persistent, so your computer >> restarting, or a process restarting, doesn't clear the stack. >> - the undo/redo user commands must apply to revision control operations >> like create branch, switch branch, merge, revert to previous version, >> etc. My favourite way of justifying this is to just look at the number of >> questions on stackoverflow.com of the form "Help, I accidentally did XYZ >> to my git/svn/hg respository, how do I undo it?" ;-) >> - applications need to have significant control over how undo/redo are >> implemented. It's part of the UI design and we don't want the database to >> be too limiting. >> - the main failing of my ProjectDemo app was I never attempted to >> implement normal undo/redo. It was still a useful testbed for validating >> ideas, though. > > Do you have some detailed notes about this last discussion? I don't remember > the details of what we discussed. I should have written some notes, but I > haven't :-( > I didn't keep detailed notes either :-(. But I think the above points were the main conclusions, along with the point you mention below about ensuring editing one document doesn't cause changes in another. >>> Furthermore, I wanted to promote some discussion on OM4. I've identified >>> some issues that come to mind: >>> >>> 1) Object Roots >>> >>> OM4 does not seem to provide a way to separate "core objects" so that you >>> have separate object graphs that cannot overlap - it seems everything in >>> the same repository can reference any other object in the repository. >> >> I originally did this because I wanted to avoid giving special properties to >> 'root' objects. My motivation for that principle is taking a 'root' document >> and moving it inside a document shouldn't change its properties too much >> (how it responds to revision control, etc.) I'm not totally sure how >> important that is, though. >> >>> On first thought, this seems to be okay, but it makes it almost impossible >>> to work on the same repository from different processes without a >>> synchronisation or notification mechanism (which I don't think sqlite3 can >>> provide). >> >> Yeah, it'll take some extra work to support simultaneous editing between >> multiple processes. >> >>> We need object roots at some point so that we can identify the top-level >>> objects in a users workspace during search. >> >> I'm not sure it's absolutely necessary - say you have a set of search >> results which include sub-nodes of documents; you could navigate through the >> nodes' parents until you hit document root nodes. >> >>> Having a table for them would also help with indexing because we could >>> store the object's type (used for opening it) and the date it was last >>> created/accessed so that we can improve search results (i.e. put more >>> recently accessed objects first in a search). >> >> That sounds good. >> >> Overall, segregating objects is probably a good idea. My hunch is that it >> should be mostly an implementation detail and not have any observable effect >> on the use of the library, but I'm not sure. > > This sounds like the discussion we had about embedded core object vs > standalone/root core objects (aka persistent roots), and the need to ensure > that other documents usually don't change behind the user's back on editing > another document, unless it's clear a document kind involves explicit sharing. Right. > 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. Regards, Eric _______________________________________________ Etoile-dev mailing list [email protected] https://mail.gna.org/listinfo/etoile-dev
