[Bf-funboard] Re: Undo Possibilities / What's the problem?

D.J. Capelis bf-funboard@blender.org
Tue, 14 Oct 2003 21:39:47 -0700 (PDT)


>I'm no coder ...
>but your talk about diffs seems odd to me.
>For me a diff contains the difference between 2
states >or files.
>Like a patch.

Exactly...

>What is the benefit of computing the diff between the
>actual state and the state before the last operation?

You'd have to do the same anyways, you might as well
keep a log of the changes to the actually .blend
file... it would probably be easier.

>And do you realy want file i/o after every operation?

Sure, if it's not too much, if it is, go ahead an plop
it in RAM.

>If ressource usage is a topic, I guess the only sane 
>way of handling undo is to log operations and make 
>them reversable. 

This is exactly what happens... the actual effects of
the operations on the .blend are calculated and
stored.

>Oh, reversable operations ... is that the problem?

If you keep a log with what the .blend file is before
and what it is after any operation is reversible.  If
it doesn't change the .blend then it's not much of an
operation and you'd lose it on program shutdown.  So
no, reversable under this wouldn't be a problem.

>However, I would rather like to see an undo-system 
>done right in a later release, than a hack in an 
>earlier one.

It could be a very beautiful system if done properly. 
It's hardly a quick hack.  It's also clear that if a
better method isn't gonna pop up soon we need this
code.

>And allthough most apps do it, deleting undo-history 
>on saving the file is stupid!

Okay, make it an option, it really doesn't matter... a
series of .diffs is about the same as the file
itself... the full history could be stored, even with
the branches... though the unused branches would take
up disk space, which is why I proposed it be cut off
after save.  Although, I suppose it's not too much
load and this doesn't have to be done.  Have it your
way, this is blender we're talking about here...
little things like this are easy to change. :) 
(Partly joking... partly not.  No one gets my humor
anyways, don't be surprised if it's difficult.)

>So a very good undo-system would be omnipresent, 
>branching and persistent (undo-history saved with 
>file).

Yep, this system does that.  Hey, did you just
compliment my idea?  Thank you! ;)

=====
~D.J. Capelis~
Network Security and Cryptography Researcher.
Developer of the FOML NewSE codefork - http://se.solarmatrix.net

__________________________________
Do you Yahoo!?
The New Yahoo! Shopping - with improved product search
http://shopping.yahoo.com