-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I very much like Tomeu's version model, but I am also unsure whether I have interpreted it correctly.
My feeling is that each object in the Journal is associated with a tree of versions. The tree has one node with no ancestors: the root node, which represents the initial version. The tree also has at one or more nodes with no children: these are the "leaf" or "tip" nodes, which represent the most recent versions. Resuming any version and editing it produces a new node whose ancestor is the node of the version that was resumed. An editing session that contains many incremental saves may produce a long chain of such nodes. ~From a user interface perspective, I think the idea is extremely simple. Each object is actually a leaf from the version tree, and the detail page of an object shows its predecessors. This does not conflict with the Actions view of the Journal or the Objects view. The history of an object is only visible in its detail page. Under normal circumstances, editing an object causes that object to move up toward the top of the Objects view, but does not cause any duplication. Keep also does not induce a duplication; it just ensures that a new leaf node is made for the current state. The only way to duplicate an Object is to explicitly resume an old version from the version history in the details view. When that resumed instance is saved, either automatically or through the Keep button, a new leaf node is created, and so a new entry appears in the Objects view. Adopting this idea would make the current Journal behave like the future-designs Objects view, with each object appearing only once, rather than once for every time it has been edited. We may then add a separate Action view to complete the future-Journal. - --Ben -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkjj2qIACgkQUJT6e6HFtqRRIACdF+5ZOi/+qe6mPXCfS7OE3RYz 4GYAoJA3mpl+3HbKMi2fiUHRED1BWfEj =NZQm -----END PGP SIGNATURE----- _______________________________________________ Sugar mailing list [email protected] http://lists.laptop.org/listinfo/sugar
