[Date Prev][Date Next][Thread Prev][Thread Next][Author Index][Date Index][Thread Index]

Re: User representation of orgls & berts



> From: acad!alce!greg (Greg Lutz)
> 
> []It looks like what Ravi is
> trying to do is compress "uninteresting" intermediate states out of the
> trace, e.g., when you've done a dozen edit/saves and want to revert
> back to the third one, it might not seem to make much sense to enter
> nodes for each of the individual reversion steps into the trace.  But
> in fact, I think it does.  The way to accomplish what Ravi wants is an
> atomic multi-step reversion operation, which in my career I've seen
> provided by just one editor/file system, that of the Univac 1100
> series.

I thought we already had hooks for this, with the fine/coarse/working/
...(as many levels as you want).../release/.../canonical berts.
So a trace could be as fine or as coarse as you wanted.

Suppose several were displayed in a trace tree simultaneously:

	 (((w)))
	    |
	   (v)
	    |
	  ((u))
	    |
	   (t)  (x)
	    |   /
	 (((s)))
	    |
	   (r)
	    |

where the finest-grain bert went -r-s-x-s-t-u-v-w, a coarser one went
-s-u-w, and a still coarser one went -s-w.  You could collapse out
the finer grained stuff when you're not looking at it, in the same
way you do with an outliner, i.e. with just the two coarser grained
berts displayed, you'd have:

	  ((w))
	    |
	   (u)
	    |
	  ((s))
	    |

and with just the coarsest bert displayed, you'd have:

	   (w)
	    |
	   (s)
	    |

Display of finer-grained berts need not be all-or-nothing.  You
could, say, double-click on the line between s and w, to open up
a level of finer structre that passed through there.)

If the finest bert or two don't have "record history" set on,
their history goes away automagically when you end the session.

Though this example shows the berts hoping hiearchically, there
is no reason they must.  You could use colors, or other icons, to
represent a trace tree where the berts hopped in arbitrary order,
or even visited divergent versions, and get the same result when
you selectively suppress the display of various berts.  (I'd expect
mostly-nested to be the predominant pattern of use - especially
if we make it easy for the users by giving them this form of
display.)

You'd want to use, say, colored arcs to represent this more
general tree.  Perhaps something like this:

	    w
	  //|
	 /( v
	|  \|
	|   u
	 \ /|
	  X t  x
	 / \| /
	|   s
	|  /|
	| | r
	| | |

(Note that it gets cluttered fast in black-and-white typewriter pix.)

Reversion, of course, would not be by a command that backs you up
by one edit state.  Instead, you'd grab the icon representing the
bert associated with your edit window and drag it to the document
state you want to view.  The frontend tells the backend to make it
a real bert-hop when appropriate, for instance, when you:

 - make an editing change from the new state
 - nail it down (with a double-click?)
 - hop a bert with no associated window open

Double-clicking on a state with no bert creates a new bert on that
state, and opens a new window to view/edit the document through the
new bert.  Double-clicking a bert-in-the-tree with no window opens
a window.  (Double-clicking on a flock of berts at a given document
state might open a selection window so you can clarify which bert
you meant.)

	It that "More" like it?
	michael

PS:  This has given me several thoughts on history tracking.
     Perhaps more on that later.