Share this post

Link to post

Share on other sites

Or an insanely insane one! Complex drawings can have literally thousands of objects: I don't think it's generally useful, let alone practical, to have the software keep track of every little change to every single one of them.

Share this post

Link to post

Share on other sites

Artem I'm not sure if this is in the Feature Request forum (in on my smartphone) but you should DEFINITELY add this idea. Ad far as UI, It could be a simple switch in the History palette to switch from document History to Object history...

Your history have already write all info about all object. And I want using only history info about one object.

And I'll bet. There have been cases when you made a number of revisions, but decided to revert back without overwriting the new actions. And in this case such history can help you.

Now, of cource, I can use hack. Revert history to needed state of object cmd+c, then to end of history and cmd+v. But it is not such content-depending

Share this post

Link to post

Share on other sites

I wonder if it would be possible for the history steps to be independent of each other? Here's my idea: If the steps are independent and the user could name the steps so you know what object they pertain to, then if you wanted to you could uncheck a step you wanted removed without affecting the rest of the art. I say uncheck because if you wanted to you could recheck it to put the step back or if you did something else to the object at that point, the checked step would be removed and your latest action would be recorded. Don't know if it's too complex to be done and it would require the user to name each step to make it work.

Share this post

Link to post

Share on other sites

While it sounds wonderful, a non-linear undo history is very very difficult to implement. Our history stack relies on deterministic state at each stage - it's the only way to make sure of data integrity and predictability without doing a lot of costly validation. If you could optionally undo, remove or change random bits of the history the deterministic state does not exist - a previous history change invalidates the predictable state of the document later in the history.

Many years ago I worked on a project where someone insisted we tried to implement non-linear undo. It was a total failure. We went back and rewrote everything with a conventional linear undo stack.

Some tools implement something similar to non-linear undo through modifier stacks, but these are notoriously hard to understand from a user perspective.

Share this post

Link to post

Share on other sites

Do y'all keep track of each objects ID in AD? If so, if there is an object selected on the artboard, would it be possible to filter the history by object ID? And if nothing is selected, then present the history fully as now?

Share this post

Link to post

Share on other sites

Ben, thanks for the explanation. So history is done based on the changes made to the document and the deterministic state is the total document? I gather it's not practical to record history based on objects instead of documents? So if I understand your explanation, if I delete an object and the history is non-linear (or object oriented), there isn't a way to easily validate that deletion at a later point in history. Without linearity, the means that the only way to handle history would be to basically replay all the previous steps up to the selected point? And I presume that the issue is compounded since history can be saved within the document and that document can be opened in multiple apps.

Share this post

Link to post

Share on other sites

We generally use pointers to identify an object. They are unique and we don't have to use arbitrary ID values that require special management.

Unfortunately, identifying what has been changed in a given command can be quite involved. Without giving away too much about our architecture, our commands follow a number of different forms: some do one-off calculation and swap data, others have to do some work, in order to do/undo. In order to work out if object X is affected by a command would require knowledge of how object X exists as it is affected by a sequence command. What is logically an object that goes through changes might actually be a totally different memory object under the hood between commands.

Share this post

Link to post

Share on other sites

Ben, thanks for the explanation. So history is done based on the changes made to the document and the deterministic state is the total document? I gather it's not practical to record history based on objects instead of documents? So if I understand your explanation, if I delete an object and the history is non-linear (or object oriented), there isn't a way to easily validate that deletion at a later point in history. Without linearity, the means that the only way to handle history would be to basically replay all the previous steps up to the selected point? And I presume that the issue is compounded since history can be saved within the document and that document can be opened in multiple apps.

Something like that, yes. ;)

Trivially, if command A creates an object, and command B sets that objects colour, what happens if I remove command A from the history???

Non trivially - with a more complicated scenario - it's a total nightmare.