[SOLVED]Suggestions on undo/redo functionality for an image processing app.
-
I am sort of moving ahead on this project I was trying to do with the double image viewer.
I am at the point where I want to be able to create a small history of the user's actions.
Lets say that for example he wants to display the negative of the image he just loaded. He only has to press the "Negative" option from the menu. After the operation is done I want to display an item in a listWidget saying something like "operation negative" or something similar. After a bit the user might have selected a number of other options etc. So the list will slowly start to fill with user actions.
At any point if he wishes he can click the corresponding list item and be transported at that position (so basically he will get his image as it was at that point).
Has anyone an idea of an efficient way that I could implement this. Saving the image in ram after each operation seems not all that good of an idea, because after a few operations the program will need a lot of ram to operate. Would saving the image in a temporary file and reloading it be a good idea?
-
Hi,
What about cache + temp files ? Keep the last X frames into a cache and then start using the disk ? Also, depending on the operation you do, you can also just save the operation itself, e.g. change blue from 255 to 185, then apply that operation backward.
Hope it helps
-
Hi SGaist,
As usual yes you helped a lot. I thought about your second suggestion, but those operations could possibly be very complex and might need some time to run. In that case the user will have to wait. Users hate waiting :)
Moreover, there is no guarantee that there will be a procedure that is able to reverse the algorithm, so we go back at saving frames.As for your first suggestion, I have used cache once during the development (ongoing) of my QtServer, but I am not sure on how am I to implement it. For example how will I distinguish each frame, locate it in cache or disk etc. Thus I will have to do some tests and get back at you.
-
That's why, when possible, you give them visual feedbacks of what is happening.
That's why you should handle each operation the "correct way", meaning that the non-destructive operations can be stored as just command to be reversed, and the other operations should store the original state before the modification.
-
That sounds indeed like the right way to go, but for the moment it seems a little bit hard to create a container able to store and distinguish between those three methods of saving previous states.
I think I should start with the simplest of them all, namely cache, and progressively implement the others. So I will store lets say up to 10 frames with a unique id and call them as needed.
