Hey Eric, Le 6 mai 2011 à 23:34, Eric Wasylishen a écrit :
> Hey Christopher, > > On 2011-05-03, at 6:22 AM, Christopher Armstrong wrote: > >> 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. > 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 :-( >> 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. 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). Cheers, Quentin. _______________________________________________ Etoile-dev mailing list [email protected] https://mail.gna.org/listinfo/etoile-dev
