[Dev] Undo and commit()

[John Anderson]

Reid Ellis wrote:

> On Tue Jan 3 2006, at 14:22, John Anderson wrote:
>
>> Alec Flett wrote:
>>
>>> John Anderson wrote:
>>>
>>>> I was hoping, someday, to have the commit point be the unit of  
>>>> undo, e.g. if you did a delete, you'd commit after the operation.  
>>>> Of course this requires the ability to roll back changes to  
>>>> previous commit points, which doesn't yet exist.
>>>
>>>
>>> Personally, I think that trying to tie Undo transactions to  
>>> repository transactions is going to land us in a heap of trouble.  
>>> I'm all for thinking of Undo-able actions as a series of  repository 
>>> changes, but there is a disconnect between what the  user probably 
>>> considers "undoable" events and what the repository  considers 
>>> uncommittable.
>>
>
> Most undo/redo mechanisms I've dealt with:
>
>     (a) are not tied too tightly to the data representation (using  
> database rollback as the only method of undo)
>
>     (b) do not act on UI changes (e.g. changing from week to day view)
>
Most applications I've worked on implemented undo this way. However, one 
applicaiton that I worked on was tied to the repository. It was by far 
the nicest because it didn't require and any extra work by the 
programmer implementing a command, wasn't buggy and worked consistently 
everywhere.

> I would argue that undo/redo should be achieved by parcelling up the  
> code into "actions", similar to what Alec described, that know how to  
> change the state of the model in both directions, thus being undoable  
> and redoable. Based on what I've seen about how the repository is  
> tied to both UI actions and external actions (like new mail), I do  
> not think it would be a good idea to tie the undo architecture to the  
> repository. Rather, they would make additional repository changes in  
> order to achieve their required state change.

I don't really care about whether it's implemented as roll back or 
playing some repository change log forward, all I care about is that we 
automate the work necessary to keep track of changes so that I don't 
need to write any special code when I implement a command -- except 
perhaps for saying where the undo points are and what the name of the 
command is.

>
> Perhaps as an optimization, they could check for external changes,  
> and if there are none, then use the repository's rollback mechanism,  
> but even that seems difficult, based on what Andi said about not  
> being able to discard changes (or is that something that is coming  
> soon?). Regardless, it goes out the window if something else happens  
> like getting mail in the middle of doing undo/redo.

As I mentioned earlier, when undoing we do need to merge in changes to 
the repository from other threads, so, for example newly arrived mail 
isn't lost when you undo.

>
> Is the "rerender" mechanism actually just marking items as "dirty",  
> or is it forcing them to draw?

Rendering creates widgets and synchronizes them to the state of the 
blocks (blocks persist and widgets don't).

>
> Reid
>
>>>
>>> Here are a few scenarios that I think would cause us trouble if we  
>>> were to tie undo points directly to calls to commit()/uncommit().  
>>> I'm using the term "undoable change" to be a user-comprehensible  
>>> change, such as deleting an event or changing data in the detail  
>>> view - one that the user would consider "undoable" by selecting  
>>> Edit->Undo. I'm using the term "uncommit" to refer to playing back  
>>> a series of changes in reverse order - this may or may not mean  
>>> simply rolling back, as you'll see below.
>>>
>>> Scenario 1: an undoable change may actually span multiple commits
>>> A user makes an undoable change that causes commit() to be called  
>>> three times just because of the codepath it follows happens to  have 
>>> an extra commit() or two.. (maybe it goes through sharing and  that 
>>> causes some repository view manipulation) Now any sort of  "Undo" 
>>> command would have to be run three times to uncommit that  single 
>>> user action
>>
>> In past systems that used a mechanism like I'm proposing, you can  
>> avoid this problem quite easily. Organize your code into operations  
>> that do work, but don't commit. A command calls one or more  routines 
>> that the work then the command does a commit at the end  (Actually, 
>> to be more precise, each time a command was begun it  commited the 
>> last commands changes)
>>
>>>
>>> Scenario 2: A user manipulates the UI after making an undoable change
>>> A user makes an undoable change, and then clicks on another  
>>> collection. Thanks to CPIA, changes in the UI are also changes in  
>>> the repository. This means that "Undo" operation might actually  
>>> just cause the user to switch back to their preview collection. It  
>>> would take a 2nd Undo operation to actually "undo" the original  
>>> change.
>>
>> I'm not sure I understand this, but if you mean that undo moves the  
>> user interface back to exactly what it was when you did the last  
>> commit, yes that's the way it works and this is what you expect --  
>> undo should get you back to exactly where you were, view included.
>>
>>>
>>> Scenario 3: Some changes might occur in different repository views
>>> A user makes an undoable change, and that change may cause changes  
>>> in multiple views - i.e. sharing. What exactly do we "undo" when  we 
>>> uncommit?
>>
>> If I understand this, another variation of it is the following:  
>> Suppose while you're doing some operation, new mail arrives, when  
>> you undo you don't want to undo the getting of the new mail. This  is 
>> a real problem. One possible solution is to save information  about 
>> changes to the repository from other threads and when you  undo (roll 
>> back) replay (merge) those changes into the repository.
>>
>>>
>>> Personally, I think we need to be very explicit about undoable  
>>> changes. I think we need to bracket such changes with some sort of  
>>> begin/end undoable transaction mechanism. We can still exploit all  
>>> the benefits of the repository though - for instance:
>>
>> Currently, there is no obvious rule about when to do a commit, so  it 
>> ends up being a little arbitrary. This would eliminate the any  
>> confusion about when to do commit.
>>
>>> 1) an undoable transaction might just be a pair of repository  
>>> version numbers - and we just play back all the changes backwards  
>>> from the newest version to the oldest. (i..e even if we're at  
>>> version 103, the previous undoable change might be from revision  
>>> 100 to 101, so we'd just play the changes backwards between 101  and 
>>> 100)
>>
>> Yes, I agree something like this makes sense
>>
>>> 2) notifications would fire when we play back the changes, so the  
>>> UI would (hopefully) stay up to date
>>
>> To keep the UI up to date, all we need to do is unrender the UI,  
>> roll back the repository, then rerender it (which also calls  
>> synchronizeWiget)
>>
>>> 3) perhaps we could even look ahead at the changes to be played  
>>> back, to see if an undo operation is even valid. (i.e. if it might  
>>> cause conflicts or something)
>>> 4) Redo support would be easy - even multiple redo support like in  
>>> Word/etc.
>>>
>>> An explicit Undo mechanism gives us another advantage: we could  
>>> assign user-visible names to the undo actions.. and then we could  
>>> display that user-visible name in the edit menu, so it might say  
>>> "Undo Cut" instead of just "Undo"
>>
>> In another system I used based on a begin/end mechanism like  commit, 
>> commit took an argument which was the name of the command,  e.g. 
>> "Cut", which was used to keep the menu up to date.
>>
>>>
>>> Here's an example of this system in action:
>>>
>>> UndoManager.BeginTransaction(_(u"Cut"))
>>> self.CutSomething()
>>> UndoManger.EndTransaction()
>>
>> If your BeginTransaction happened to call commit, I think we could  
>> eliminate explicit commits and our proposals would be identical.
>>
>>>
>>> Maybe there's even a more pythonic way to handle this:
>>>
>>> UndoManager.DoTransaction(_(u"Cut"), self.CutSomething)
>>
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
>
> Open Source Applications Foundation "Dev" mailing list
> http://lists.osafoundation.org/mailman/listinfo/dev