On Tue, 05 Jul 2011 14:39 -0600, "Eric Wasylishen" <ewasylis...@gmail.com> wrote: > Hey Christopher, > Thanks a lot for the additional explanation!
No problems :-) > > > For simplicity, object branches should probably be named to distinguish > > them from one another, but we could autogenerate the names to make sure > > they are unique for an object and permit the user to rename them later as > > they saw fit. > > Regarding names, Quentin's idea was "no name-based references in > CoreObject; UUID's everywhere" - which is pretty much what you suggest. > You can then map human-readable names to UUID's, freely edit the names > without fear of breaking anything, full-text-search index the names, etc. > :-) Ok, that sounds quite sensible. > > The primary consequence is that a view merely references a branch, and that > > a view has NO history. I'm not sure if this is a bad limitation - if a view > > stores only the state of the view (such as e.g. list mode or icon mode in a > > file explorer), this is not the kind of operation that should be > > "undoable". On the other hand, if it is possible to edit a view (such as > > the layout of toolbar buttons) in a special editing mode, a view should > > have history like any other object. My thinking is that this is workable if > > a view's design is its own object with its own branch. > > 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. This is cool, but I'm not sure its possible to support without limiting objects to exactly one view. When we start adding this stuff into the undo history, it effectively becomes part of the history of the object too, and they are hard to untangle. Once objects can only have one view, any linked versions of the object (for example, embedded in another document) will suddenly change their appearance based on the changes made in another instance of the view. In this case, we'd probably have to create a new branch of the object and constantly remind the user to merge them back and forth, which is a solution I don't like. I really have no answers for this right now. 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
