adforum Posted January 1, 2015 Share Posted January 1, 2015 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. Quote Link to comment Share on other sites More sharing options...
ronnyb Posted January 2, 2015 Share Posted January 2, 2015 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? Quote 2021 16” Macbook Pro w/ M1 Max 10c cpu /24c gpu, 32 GB RAM, 1TB SSD, Sonoma 14.4.1 2018 11" iPad Pro w/ A12X cpu/gpu, 256 GB, iPadOS 17 Link to comment Share on other sites More sharing options...
Dave Harris Posted January 2, 2015 Share Posted January 2, 2015 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. Quote Link to comment Share on other sites More sharing options...
adforum Posted January 3, 2015 Author Share Posted January 3, 2015 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. ;) Quote Link to comment Share on other sites More sharing options...
Staff Ben Posted January 5, 2015 Staff Share Posted January 5, 2015 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. Quote 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 Link to comment Share on other sites More sharing options...
Recommended Posts
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.