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

Perverting Revert



I have some specific comments that I may send later, but let me give
you a few general reactions, and then propose a solution inline with
your suggestions that has lots of power, but is not too much work....

1) Though it may look it, we're not suffering from featuritus.  If we
were doing algebra, this would just be the intermediate term expansion.

2) In particular, we're searching for an upwards compatible extension
to the Mac standards of Undo, Revert, and Save.  There is no a priori
reason that elegant and compatible extensions can't be found.  The
existence of a standard should not prevent us from exploring that
space, if desirable.  We have several obvious directions to look (my
revert-as-edit suggestion seems quite compatible, if squinted at
properly... :-)

The idea MarkM and I came up with was to use inclusion lists as the
display (and perhaps representation) for the historical trace.  The
main path between the original of the document and the the current
state of the bert could make up the first level of siblings, and
branches off that path would represented as children.  The user could
then nicely control the extent to which he observes the alternate
routes.  The starting header for a given Stamp would be the time of
Save.  Editing it gives it a name that can be found upon later
perusal.  Bringing up the 'document' behind it would either hop the
bert to that Stamp and bring up the original window, or open a new
window on that Stamp (depending on the state of the option key :-).

This gives the separate Menu operation 'Historical Trace'.  It also
makes a place holder for our more graphical versions of this.  It lets
us do the minimal correct thing for Undo/etc.  It lets the user store
states of the historical trace, edit it, associate names with document
states, etc.  And it reuses all the navigation and display stuff that
we have to build anyway. 

dean