A possible undo system

[Liviu Lalescu]

Hello,

There are many users requesting an undo system.

It might be possible something ugly: save the whole current data file in memory, maybe archived with gzip (something very fast). I can see that an ~8 MB file (very large) is archived to ~250 kb. Assuming an 100 operations history, this would occupy 100 * 250 kb = 25 MB of memory, not too much.

What do you think?

Of course, even such a primitive undo system would be quite difficult to add, but much easier than a good one, which only records the operation.

[Volker Dirr]

hmmm....
maybe there is a third variant. Not sure, just a idea.

Instead of a "correct" undo where you save the modified values, you just store the whole oldConstraint.

If you add/modify/delet a constraint, push this on a list:
struct undo{
*oldConstraint;
index
}

if you add a new constraint, den index=indexOfNewConstraint and *oldCOnstraint==NULL
if you delete a constraint, then index=indexOfOldConstraint and *oldConstraint=oldConstraint
if you modify a constraint, then infex=indexOfOldConstraint and *oldConstraint=oldConstraint

So if you want to undo a change, then you pull that from the list again and:
delete constraint(index);
add (if !=NULL) the *oldConstraint.

[Vangelis Karafillidis]

Liviu, why not a temporary file in the same folder as the original .fet file? When one opens the .fet file, could a "clone" of this file be created automatically and then for each action to create a new temporary file? These temporary files could be saved as a gzipped (.gz) file. If the user closes FET, without saving his .fet file, the temporary file (.gz) should be kept. But, if the user closes FET after saving his work, this .gz temporary file could be erase automatically. Or maybe, could be asked if he wants this .gz to be kept or removed.

[Liviu Lalescu]

@Vangelis Karafillidis : it is not nice. Also, very time consuming.

[Liviu Lalescu]

@Volker Dirr , this is the good approach I was talking about. Difficult. Also, please consider that I might remove an activity (teacher, etc.) or modify a teacher (etc.) and 100 constraints with it.

[Volker Dirr]

ah.. Ok. I was a bit confused about the compression.

I forget that deleting a teacher might also delete a lot of other constraints. will be difficult to care about. It's also importend that if you restore the data, then first you need to add the teacher and then add the other old constraints. hmmm... complicated.

i thought your first idea is to do a copy of all constraints. So you need much more memory, but on the other side restoring might me much easier.

[Liviu Lalescu]

Zipping the whole data and restoring it is difficult.

I have another idea.

I just made a test. You can check on the attached files, overwrite and recompile (on FET-6.8.0 official), and open the attached fet file, go to activities dialog, and press Help.

The fet file has 19437 activities and 5352 time constraints (artificially, not solvable, made by me from the German example).

It takes I think 3 seconds for 1000 operations of copying the rules, while removing the first activity and time constraint (and space constraint, but the file lacks these). Memory increase is ~200 MB on my computer. So, an undo and two operations for this very large file would take 3 ms and 200 kb of memory. Acceptable, in my opinion. Other files are much smaller.

Note: The Rules class is much smaller than the fet file.

Note: Qt uses shared data, which is helpful.

Now, all I need to do is to copy the rules in any operation. There are about 400 places.

I am confident it might work.

I think we should make default undo/redo unchecked. The user can select it, and can select the max number of undoes.

Please tell me what you think.

[Volker Dirr]

Sound nice. I will read source tomorrow. It's to late now.

About the undo: In tools like witer or similar is is possible to "see" what you undo, since the courser jumps to that position. so you can see changes.
i guess/think somethink like that is also needed with the undo. Maybe even write a dialog that displayes the new and the old items, so i can see the differences and confirm before doing the undo.

[Liviu Lalescu]

How to write a dialog that displays the new and old items? I don't understand.

Of course, I'll record a generic name for the operation done ("Locked activities in students time horizontal", "Removed a time constraint"). Do you have other suggestions? And I think also to record the time of the operation.

Also, don't forget we have also redo. So no need for confirmation.

Tough way ahead 

[Zsolt Udvari]

I use a version control system to manage changes in FET file (prefer subversion but git or any other is good). It works very good because of text-based XML file.
I don't know how many work integrate one of them but IMHO it would be a good choice.

Possible workflow: at every save FET will ask the user summarize the changes ("changelog"). Later can undo any change and can see from changelog what will be revert.

[Volker Dirr]

@Liviu: I think just write the description of the constraint like in the constraints dialog. Write the old description and write the new description. so a user can compare.

@all: in practise i always do it like this:
as long as i am working to input the activites and check if all activities are correct, i deactivate constraints that makes generating slow. so espacially i deactivate the max gaps constraints.
as long as i am working on this i don't need undo. genarting is fast and can just fix bugs as soon as i see them.

2nd step is working on the constraints. most constraints are already activy. Now adding/activating difficult constraints. Generating need much time, so i might forget what i have modified. So save the file with a different name (just adding a number), so if it fails to generate and i can't see the reason, then i need to step back. So in fact i just need 1 undo step.

[Liviu Lalescu]

Would it be useful to allow more than say 100 undo/redo steps?

I think we will make an unlimited history mandatory, and the user can select if he wants also undo/redo (default unselected). And the user can select the number of undo/redo steps? Or default 100 undo steps and enabled?

Also, the user can click directly on each saved state, without the need to click more times undo?

Also, record the time of the operation?

[Liviu Lalescu]

Hmm... sorry 

It is not at all that easy. I think I cannot do this...

[infoo_]

Hello all

Since FET file is an XML file, wouldn't it be easier to figure out how to use/copy the undo system that has a program capable of opening an XML (e.g. Windows Notepad or VS Code)?

In these programs the undo system is already implemented, perhaps it can be extrapolated to the FET environment.

[Liviu Lalescu]

I we work on the XML, it would consume much memory and time.