Hi Quentin On Wed, 06 Jul 2011 12:02 +0200, "Quentin Mathé" <[email protected]> wrote: > > > > 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.
Ok, I understand now :-). Its the ability to arbitrarily interleave the library and individual photo histories for one editing context (when working in Photo Manager) which uses history tracks, and still being able to use the histories on their own (library editor and image editor). > 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) I agree. > 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. No problems, I think we're on the same page. Eric has suggested it would be nice if the undo history contained operations such as * text selection * navigation using the scrollbar * changes to the layout (e.g. switching between table layout, outline layout and icon layout) * changes to the window position What I was pointing out was that I can't see a conceptual model where you can have these operations interleaved in the undo history for changes to an object, but also have multiple views of the object that are automatically synchronised between each other. If we do what I originally described, we can still persist the state of the view when it is closed, but we can't include those sorts of view operations in the undo history of an object/branch. A view state would just be the latest copy of the document tree, persisted as a blob (no history). I've been giving this alot of thought, and I've come to the conclusion that whilst it would be very nice to include some of these operations in the undo history, it prevents us from having multiple views of an object, which is too limited given some of the use cases such as photo library and image editor, a split code editor view or word processing document view, etc. Each view would have to be synchronised, and this would synchronise the view operations (which is useless) or it would create different undo histories in views which should be conceptually the same. I think we need to just find pragmatic solutions to making these sorts of operations as easy to undo as possible, but in a separate way. For example, navigation using the scrollbar is something I would really like to be able to undo from time to time. I notice that modern web browsers support this when you click on links to anchors in the same document. I think we could support a sort of "back navigation" by leaving markers in the scrollbar colour coded as to where the last, second last and third last scroll positions were, and then allow the user to click these or use a shortcut key to navigate back. It would be cleaner in the undo history, but that just causes the problem I outline above. For text selection, its probably possible to implement something like the multiple selections that is outlined in Jef Raskin's book, but this would require some serious changes to the GNUstep text machinery. The other operations I don't think are important to make undoable as they are really just "mode" operations which are easily reversible. Hope that clarifies things. Cheers Chris -- Christopher Armstrong carmstrong ^^AT^ fastmail dOT com /Dot/ au _______________________________________________ Etoile-dev mailing list [email protected] https://mail.gna.org/listinfo/etoile-dev
