On Wed, Apr 22, 2009 at 10:49, Sascha Silbe <sascha-ml-ui-sugar-de...@silbe.org> wrote: > On Fri, Apr 17, 2009 at 02:06:55AM +0200, Sascha Silbe wrote: > > [Mockups] >> >> The second one [2,3] modifies the date field to be a combo box, like >> shown in Journal Designs #12 [4]. > > The fine thing with mockups is that they show just what you imagine, not the > complicated reality. > > How do we actually handle branches? > > Option 1: > * show all versions in the branch of the current entry, including all > ancestors on "super" branches (i.e. 1.1.3 shows [1.1.3, 1.1.2, 1.1.1, 1.1, > 1]) > * rebuild the date/version box on selection of a version > + consistency: no matter how you got to the current version, it will always > look the same > - oneway: once you select a version on a "super" branch, you're stuck to it > and can't change back to the originally chosen version anymore. > > Option 2: > * show all versions in the branch of the current entry, including all > ancestors on "super" branches (i.e. 1.1.3 shows [1.1.3, 1.1.2, 1.1.1, 1.1, > 1]) > * always show the date/version box of the originally selected version > + oneway: you can go back to the originally selected version from any > ancestor > - consistency: depending on where you entered the tree, you'll get access to > different versions. > > Option 3: > * only show direct linear ancestors, not "super" branches > + no consistency or oneway issues > - no access to earlier branches, i.e. any load+save of a non-HEAD version > will cut the entire ancestry for the just saved version > > Option 4: > * flatten and sort the entire version tree according to the date > + no consistency or oneway issues > + access to all branches/versions > - no information about ancestry, an intermediate version might lack content > that both "neighbors" (in the list) have > > > Thinking about it, Option 4 is probably the way to go for now (unless > someone can come up with a smart #5). Rely on the user to tag the documents > well enough to avoid confusion. We probably want to revise this decision > later when we got some experience with actual user behaviour.
#2 doesn't sound too bad to me. Regards, Tomeu _______________________________________________ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
