Le 23 juin 2011 à 08:19, Eric Wasylishen a écrit : > 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.
ok, I'll do that :-) >>> 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. Yes, that sounds like the main points. >> 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. We can begin with a model that involves explicit root objects… If we figure out it's possible to remove the explicit root object support and still meet our needs or the same behavior, then we can remove it. I don't think that would imply many changes in the overall design and implementation. > 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. It depends what you mean by import/export. Is it about foreign world compatibility, in other words importing/exporting to/from a CoreObject database, or is it about some import/export notion within a CoreObject database? For my next replies below, I'll assume it's the second case. > Maybe if we wanted to emulate that, we would just make the library a > persistent root, and the photos would be embedded objects. Hm, I'm not sure to see what the common use case could be… Any example? If I have photos in a library and I place them into documents, I expect the changes I made on the photos with the Photo Manager or a Photo Editor to be reflected in all the documents where I placed them. As a special case, when I want a copy/snapshot, I would press the option key on a drop to get a copy inserted (or click a checkbox if the photo insertion goes through a dialog). > 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. Yes, but I doubt that's the behavior you want or expect by default. > 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. If compound documents don't share objects automatically, but you have to request it, that seems to defeat a bit the compound document notion which revolves around implicit sharing between several compound documents. Nobody has ever used a system based on compound documents in the real world, so it's hard to say implicit sharing is a right answer… but still I'm tempted to say so ;-) Either behaviors is easy to implement, even switching between both at runtime shouldn't be hard, so I wouldn't worry about it. It also seems introducing a root object notion doesn't impact the algorithm you propose. > 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. Would be a good :-) I'd say that cheap copies and branches seem to be one and the same. iirc we discussed the idea to have no branch notion at the low-level but rather copies tagged as branches… I don't remember clearly, but some ObjectMerging version might even already implement that. Cheers, Quentin. _______________________________________________ Etoile-dev mailing list Etoile-dev@gna.org https://mail.gna.org/listinfo/etoile-dev
