Hi Quentin > >>> I don't know anything about Quentin's history track idea, so this could > >>> be the same thing. > > The history track idea was about supporting arbitrary views on the entire > CoreObject graph history. By 'view', I mean a database-like view. > For example, if you have a photo library, each photo is a core object and > the library is a core object too. All these core objects are persistent > roots. For a Photo Manager unlike an Image Editor, you are not interested > in the history of each photo individually, but in an aggregated history > that combines the photo histories + the library history. An history > track could be used to model such an history. > > So history tracks would give the possibility to manage multiple tracks of > user actions based on arbitrary criterias (group of objects, kind of user > actions, edited data type etc.) . In addition, history tracks might > provide a simple mechanism to record an history if no core objects are > involved… For example, to provide undo/redo on user actions such as > window move, resize, scrolling etc. > > Eric started to work on a preliminary version in ObjectMerging4, see > COHistoryTrack.
Ok, I'm not sure how this is any different to just having a separate core object for the photo library that has its own history, or the concept I outlined before, but I'm probably missing something. > >> An undo is performed as just winding back to a previous branch pointer > >> history node by following the back pointer in the history node and > >> updating the branch to point to the history node. A redo is similar > >> (follow the forward pointer in the history node). A change in the object > >> revision (for example from a new change, a merge or a revert to a previous > >> version) is just by creating a new branch pointer history node. A > >> selection is also a new branch pointer history node, but with the same > >> object revision and the selection information stored in the auxilliary > >> field. > > By 'selection', do you mean switching to another branch, navigating to a > past version in read-only mode or something else? No I meant a text selection actually :-) i.e. something that is not part of the object itself, but is part of the way the user interacts with the object (i.e. the view). > >> All these operations suddenly become undoable because they are separate > >> from the object history. > > Yes. Now that I think about it, the main advantage I see is that it > should be easier to debug than a 'in-band' approach. > Although the 'in-band' sounds conceptually nice and clean, from I have > observed when working on the CoreObject from trunk, the history can be > hard to inspect and reason about it. For the reasons I explained in my previous email to Eric, in-band view information means that you can't separate an object from its view, which prevents having multiple views on the same object. The downside, as I also pointed out, is that views suddenly cannot have history. Anything stored in the history track is shared between the views, and anything that is not, cannot be historic. Its a blurry line unfortunately. > > >> Furthermore, cloning an object is just a matter of creating a new branch > >> on it with no branch history. > > Sounds related to cheap copies as branches. I think it is ;-). > > Yeah, I was thinking about this as well. > > I could be interesting to have switching from list mode to icon mode be > > undoable.. > > > > As another example, Xcode has those little back/forward buttons which act > > as undo/redo for scrolling and navigating between files. Sometimes it's > > really handy when editing a huge file to have undo for scrolling. > > I think they are two aspects to the problem. Either you are in UI > editing/building mode and the UI is the model, or you are in the UI > interaction mode. > The first case is easy (at least conceptually with EtoileUI), it's > basically like a Nib file, except the UI is both a compound document and > a core object rather than a Nib file. > The second case requires some extra support to record UI actions in a > history track or something similar. > > The toolbar editing case is interesting because it is an hybrid case. If > we use our own machinery (CoreObject, EtoileUI and a compound document > editor) to build the UI rather than Gorm/IB, then it can be quite nice, > because we can treat UI customization as branching over the UI that was > shipped with the application. > However we won't have a complete UI builder infrastructure before a > while, so we could initially record the customization changes in a > history track (probably snapshots of the user defaults for the toolbar). > Ok. Cheers Chris -- Christopher Armstrong carmstrong ^^AT^ fastmail dOT com /Dot/ au _______________________________________________ Etoile-dev mailing list Etoile-dev@gna.org https://mail.gna.org/listinfo/etoile-dev
