Jump to content

Recommended Posts

Hi.

 

A huge feature to have would be undo stack to be saved to affinity files. That way, we could work on projects as if we never left them.

Additionally in fact, a full versionning system could be great, but if we also could

- name some steps so that we can go back and forth in our edit history

- freeze edits below a certain point (but still see what it looked like and copy elements from those steps)

- export at some points in 'time'

- have time and date for each edit

 

This is to be able to cope with customers that cannot take decisions and be able to always get back on previous edits to show what it looked like at that moment. You could say that i should save each and every results, but you never know in advance what you will need and that is 1: a huge disk and time loss to organise it and 2: not an absolute way of ensuring that you always be able to sort things out. You cannot save everything manually.

Share this post


Link to post
Share on other sites

I've had the same idea before, and I think it could be super useful in certain phases of the design process. A check-mark in the Save dialog box giving users the choice to save their History (as defined by the number of Undos in the Preferences, would be a simple and effective v1.0 of this feature... I can't imagine file size not swelling exponentially, but really, what are all those cheap and empty gigabytes for?


2017 15" MacBook Pro 14,3 w/ Intel 4 Core i7 @ 2.8 GHz, 16 GB RAM, AMD 455 @ 2 GB, 512 GB SSD, macOS High Sierra

2018 11" iPad Pro 256 GB, latest iPadOS public beta

Share this post


Link to post
Share on other sites

We actually already save the undo history in autosaved files. We don't for normal saves mainly because of a lack of nerve. The danger comes when loading a document from an older version of Affinity into a newer version. If commands have changed, we have to ensure the new version of it can load the old version's data. We have a lot of commands, that evolve over time, and this would be a constant coding and testing burden for the future. I think we will add the checkbox eventually; we just have to find the courage to commit to supporting it.

 

The other suggestions are interesting. I believe AndyS has been working on a feature in that area that might help.

Share this post


Link to post
Share on other sites

Hello.

 

On the compatibility thing, maybe one thing to do could be a first iteration where edits are lost on version change. People could still keep the file but would only be able to see the edits at an eventual later time, once you commit to translate old revisions to a new one. (if you ever do. I'm a long time coder too and i totally understand your argument)

I do not see removing of edits as a problem on the long term anyway. It is pretty useful during the life of the project, to be able to go back and forth. Once the project itself is done and customer has its product delivered, there is little reason to need such a feature.

 

Saving steps would help most of us, i believe, just by the fact of feeling as if we never left the project and the confidence of being able to go back on last steps.. (don't most of thought "i really did sh*t tonight..." when waking up after a tiring night session?)

Being able to get back on projects made months or years ago would only be needed for a few of us.

All this is IMHO, of course. 

 

Oh, and on the marketing side, it's a nice feature to brag about. ;)

Share this post


Link to post
Share on other sites

From working in the games industry, this "problem" was largely solved for art assets by Version Control, such as Perforce.  It is much more granular than saving an entire undo stack, and dependant on the user choosing to commit revisions, but the result is the same.  Version control systems usually offer ways for getting back to earlier revisions.

 

For the most part, our undo stack will create a modest amount of data unless you are doing a lot of raster/bitmap work.  If we always serialised these commands, files would get very big very quickly due to raster content.  As Dave says, we do this for autosave files already, so we have the ability to do it.  The difference is, autosave files are separate to your main document file and aren't visible to iCloud or other apps, so other issues are avoided. iCloud, for example, will update your file to cloud if it detects changes.  Without saving the undo stack, the atomic changes to most files will be relatively small, even for raster heavy documents, and so iCloud updates should be relatively quick.  We do a few tricks in the file format to try minimise overall changes to the file to help improve this.


SerifLabs team - Affinity Developer
  • Software engineer  -  Photographer  -  Guitarist  -  Philosopher
  • iMac 27" Retina 5K (Late 2015), 4.0GHz i7, AMD Radeon R9 M395
  • MacBook (Early 2015), 1.3GHz Core M, Intel HD 5300
  • iPad Pro 10.5", 256GB

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...

×
×
  • Create New...

Important Information

Please note the Annual Company Closure section in the Terms of Use. These are the Terms of Use you will be asked to agree to if you join the forum. | Privacy Policy | Guidelines | We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.