Hi Christopher, Le 6 juil. 2011 à 01:44, Christopher Armstrong a écrit :
>>>>> 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. In what I explained, the important point was that photos are root objects (aka persistent roots), so their history doesn't belong to the library history. Here is a small example: @interface COLibrary - setName: - addObject: - removeObject: @end @interface COPhoto - setName: - setSize: - setColorSpace: - setMetadatas: @end So the library object history is limited to changes triggered by -setName:, -addObject: and -removeObject:. Any photo object change such as -setSize: is stored in the photo history but not in the library history. An history track would then come into play to generate a more-user oriented library history that includes the photo changes. I think it's important to have the possibility to undo/redo on a single photo or on the overall library. Treating each photo as a persistent root with its own history, makes possible to edit the photo in an image editor and have the photo history shared be a Photo Manager and an Image Editor. If the photo changes are included in the library history, I think things would get really messy. For example an individual photo history could look like: size set to 400, 500 in image editor size set to 500, 200 in photo manager name set to 'Snowy Mountain' in object manager color space set to grayscale in photo manager And the library history: name set to 'Wilderness 2001 - 2011' remove photo 'Lake' add photo 'Snowy Mountain' add photo 'Lake' However the whole approach depends on how we handle root objects and editing contexts as that was pointed out in an earlier mail. >>>> 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 :-) ok, I got lost in conjectures ;-) > 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. ok, I understand better. Well, I'm not convinced that UI interaction history should be stored together with the object. Each editor or manager application might want to remember their view state on the core object they present in their own way. So I would make any application responsible to create the history track they need to manage the view state. You can also have cases within a single application where two views on the same core object involves distinct selection in each view. A simple example would a structured text editor where the two views are: - the document is visible in a window, and where an element in the structure appears selected - an outline inspector that allows to manipulate the document structure with a tree view and where the selection is unrelated to the main document window (e.g. the Layer palette in Photoshop or Illustrator) For a editor UI built with EtoileUI, using the document item tree as the inspector represented object can be used to make the selection state in each view clearly distinct (the document item tree is a view and the inspector is a meta-view on the document view). But still the application might want the outline inspector selection state to be persisted accross launches, then we are back to having a UI history track per application. I'm not saying it should persist the outline inspector selector, but I think the need can arise. This puts aside, I agree that having the selection state attached to the document could be nice (especially for text documents). To handle such a case, perhaps a more lightweight approach could be used. e.g. storing the last selection state as a hint/metadata attached to the document. Each application could then decide whether or not it want to use the last selection state it remembered (with its own UI history track) or the document hint. I'm not how that fits with the model you were explaining though. Cheers, Quentin. _______________________________________________ Etoile-dev mailing list Etoile-dev@gna.org https://mail.gna.org/listinfo/etoile-dev
