Oh, wow! You’re my hero Thank you very much.
As I was further playing with it last night, I came to the conclusion I will have to keep the code that (temporarily) stores the autosaved file(s) in the settings. Due to the fact that a pattern can be opened from any number of folders, in the event a recovery is needed we need to know the full path of the original pattern files so we 1) know the filename and where to restore the file 2) know where the associated locked file is so we can remove it.
Got it saving backup files when saving a pattern. Auto restore is working - at least for closing the app without saving the pattern. Need to figure out how to crash the app to see if it restores open patterns with unsaved chnages. Also added the “age” column items in the restore dialog. Will display “Today”, “Yesterday” or “# Days”. May need to add a way to clear backup & autosave files from the app to make it easier than trying to locate the backup folder and deleting files.
Sera fantástico poder contar con autoguardados, en mi caso con esta nueva versión se me colapsa muy a menudo el programa con la anterior no me pasaba. Pienso que debe ser por la capacidad de mi ordenador portátil, porque con la actualización de Inkscape, también me pasa a veces. Gracias, un saludo.
There currently is an autosave feature, where if enabled every set interval (which at the present due to a bug is always set to 1 min) the program will save an .autosave file if there are unsaved changes. In the event of a crash, the app is supposed to notify you there were # number of patterns open before a crash, and do you want to open them. Theoretically this should recover your pattern(s), but it doesn’t always work.
What I’m attempting to do is extend the idea with multiple versioned (date stamped in the filename) autosaves for unsaved changes, and versioned backups everytime you save. The idea being there will be a lot more chance to recover a pattern without losing work. Also the versioned autosaves or backups would allow you to revert to a previous version of the pattern without having to delete a bunch of objects. Plus it happens automatically without having to constantly “Save as”.
Oh, dear! Ok, now I understand
So after one clicks on ‘Ok’ at the error, one should be directed to an autosave restore dialog which will close the pattern and allow you to choose which autosave you would like to restore.
Gocha! Thank you
Something like that. The app knows and catches the error exception, so it should provide a more graceful exit than just leaving the pattern open and disabled. Could make to restore either from the single autosave (easier option) or from the versioned autosaves and backups.
This probably could apply to any number of errors that can cause a crash.
Made more headway on the “restore” feature. Made a few changes to the dialog… you can now sort by any of the columns. Changed the header items to “Filename” and “Type”.
So after selecting a file to restore, a “Save As” dialog pops up… defaulting to default pattern directory set in the prefs or the last used pattern directory and the base name of the restore file selected… that is minus the date stamp and (autosave) or (backup) - in other words the original file name.
Saving will copy the restore file to the destination (original crashed?) file… and the file will then automatically open. Almost there.
That being said… in the process I came across another annoying non standard behavior in the file “SaveAs” . Normally if you SaveAs an open file, the proper thing to do is fill the File Dialog with the current filename. Not the case with the app. It always defaults to “pattern.val”. So, another thing to fix at some point.
Tweaked the size of the Dialog columns to give more space for the Filename column. Also added the Filename text as a cell’s Tooltip, which will display the full text of the filename on hover in the event it’s too long to fit the column and get’s elided.
Ok… hopefully I’ll now have time to get back to finishing this issue so we can move on.
Some updates on the new Autosave / Backup features.
There will now be a new item in the File menu… “Restore Version” which will handle restoring either an AVB - autosave file, a versioned autosave file, or a back up file. Ctrl-R is the keyboard shortcut. Just to recap… an A (autosave file) - if enabled - is created every x interval if there are unsaved changes. Once a pattern is saved the autosave file is removed. A V (versioned autosave) file is created every x interval, date & time stamped in the filename, and remains until you implicitly delete it. A B (backup file) or copy is created every time a pattern file is saved. They too are date & time stamped in the file name. You can limit the number of V & B files… if you reach the limit while saving, the oldest file is removed.
This will bring up the Restore dialog…
A context menu was added to the Restore dialog… which will allow some management of the autosave / backup files within Seamly2D without having to resort to finding the autosave directory and using the system file manager to rename or delete files. Deleting a file “moves” the file to the recycle bin, so you still can restore the restore file.
Also added is “double clicking” on a file defaults to renaming the file…
When a restore file is selected you are presented with a File dialog. Here you can decide where or what to name the name to restored file. It will default to the path and name of the original pattern file, Leaving the dialog unchanged will overwrite the original file. Note the date / time stamp of a versioned or backup file will be stripped out.
In the event of a crash OR you chose to close the app down and not save pattern files that had unsaved changes… you should be presented with the Restore unsaved files dialog. This is an update of the current autosave feature. Instead of just saying there were x number of files open with unsaved changes, the dialog now lists the files that were open at the time of a crash or you chose to close without saving. You now have 2 choices - Save and Open, or just Open. Save and Open will overwrite the original pattern files as stored in the settings… Open will just open the file as if it was any other pattern file, allowing you to Save As a new file - leaving the original file intact (albeit probably damaged).
And the latest addition is a modification to the Statusbar & Status Toolbar. - bet you didn’t know there were 2 separate bars. I first wanted to add a visual status as to the state of the AVB settings… which led to cleaning up and combining the Status toolbar into the actual “Statusbar”. That meant moving the Multi size combo boxes and the Mouse coordinates… by nature a Qt Statusbar places permanent widgets to the right of the bar… so now tool tooltips and messages will appear to the left, while the widgets appear on the right. Since the “Status Toolbar” has been eliminated that adds another 24 or so pixels to the vertical workspace… not to mention less code.
Since the mouse coordinates / units is now a subclassed widget there are a few side effects - the coordinate widgets are fixed in size. The pattern units are more visually notated, and there should be a speed increase as the pattern unit setting is not called with every mouse move.
The state of AVB or autosave, versioned, and backups are now displayed. If the setting is disabled the A, V or B will be grey. It the setting is enabled it will be green. If there is an A, V or B file created while the pattern is open, AND the A, V or B is enabled - the color will change to orange.
The tooltip messages and the multisize dropdowns remain the same with the noted change of the multisize drops downs move to the Statusbar and to the right.
Made some additions to the AVB status… added a new tool button to open the restore version dialog. Now clicking on any of the AVB tool buttons will toggle the setting to enable / disable the item. You still have to go into the settings to change the intervals and / or max number of saves.
Also changed the Restore Version icon to:
Which will appear in the menu item and Restore Version dialog window.
Fixed a few sorting issues with the Age & Date columns in the Restore Version dialog that were bugging me. The QTableWidget uses a model that sorts columns alphabetically so the Age and Date columns were not sorting by the actual underlying numerical data (age / date) , but rather by the text of the cells contents. So instead of getting say 4 day, 5 days, 7 days, 10 days, 45 days… you would get 10 days, 4 days, 45 days, 5 days , 7 days. Likewise instead of. Mon, Tues, Wed, Sat… you’d get Mon, Sat, Tues, Wed.
So… to fix that I subclassed the QTableWidgetItems (the table cells) for the Age and Date columns to sort by the items data() instead of the text().
Wow… this issue is like playing whack-a-mole. Trying to maintain a list of open files that may need to restored via autosave is proving difficult. For one thing using the debugger with multiple patterns open is useless as it appears the debugger only track the 1st app instance. Currently the app adds an entry to the settings for a file when it’s loaded… I changed this to add the file when an autosave file is written and removed when the pattern is saved. Which with 1 file is fine… issues start to arise the more patterns that are open, where there seems to be a timing issue when more than 1 pattern is trying to write to to the settings at the same time. So… I reverted back to writing to the settings only when the pattern is loaded. Problem then arises when a bunch of patterns need to be restored (after not saving or crashing)… as they all try to load at nearly the same time and again the settings restore file list becomes invalid. ARRRG. Haven’t fully investigated this, but this issue may also exist in the current build.
Going to try and insert a delay timer in the loop between loading restored autosave files and see if that resolves the issue by giving each pattern (app instance) to read & write back to the settings.
Actually while I’m on the subject of restoring multiple autosave files…
What’s anyone’s opinion on whether I should just leave it as it is, where the only option is restore (open) all the files OR have the option to choose which ones to open? I mean I’m in this deep with the issue, might as well make it good as we can .
I was thinking of instead of the current plain message box, I could have a dialog box, where by using a Qtablewidget a user could set a checkbox for those to restore?
I sometimes have more than 1 file open, but it’s very seldom that I actually work on more than one at a time, so the chances of multiple patterns crashing at the same time is minimal, since anything else would be only open as reference or to assist someone on here while I’m busy with a pattern. Even then, I would only physically be working on one file at a time.
And, normally, if the file I’m working on does crash, it doesn’t crash any other files that are open - only the one file.
That said, my brain is too tired to comprehend what your idea with the Qtablewidget would look like & work. All I can think of is that I’ve always used the “grandfather, father, son” backup system, so if I mess up a pattern with a whole lot of changes, I like to be able to go back to a point before I did those changes, so that I can try again. This way, if my pattern does crash and I open it up again on the autosave, I’d like the option to save it at this point and perhaps to restore a previous version; or to continue working on the pattern as it is after the restore.
So I’m thinking that it should be as simple as possible. Sometimes a person must remember to make a backup manually once they have done so much work that they’d hate to do it again
Granted it’s not likely a user will have more than 1 or 2 patterns open at a time, but we have to account for the fact one may have 4, 5, 10 patterns open, and/or one system may be faster than others. BTW… I have resolved the issue of maintaining the restore list in the settings - since there is already a list of which files to restore, I just rewrite the whole list AFTER all the files are open and Voila - it avoids any timing issues invalidating the restore list.
If you have multiple patterns open with unsaved changes, and one file crashes the system… or the power goes out… or < insert here > all the patterns crash so to speak. That’s the part where the (existing) autosave feature kicks in next time you start the app. Based on 3 criteria the app knows there were files with unsaved changes. An entry of the file in the restore file list in the settings. A < filename >.val.autosave exists, and the original pattern file is still locked. What currently happens is a message box says x number of files have unsaved changes… do you want to open them? Open or Cancel.
What I have done is expand on the message box to show a list of which files were open with unsaved changes at the time of a crash… or if you closed the file without saving.
What I’m asking here is whether to give the option of which of those file to restore / open. Instead of running through a dialog for each file asking do you want to open … I’m thinking instead to display a dialog with the list of files in a table - where the 1st column is a checkbox - just like the groups “visibility” eye check mark. That way the user is presented with a single dialog, and one could just check which files to restore. The reason to use a Qtablewidget is it makes it easy to parse the rows for which files are checked VS for example a Qcheckbox and a Qlabel for each file.
I’ll try a post a pic of what I have in mind if I can get my internet restored at home tonight.
Well that’s where the V and B part come into play. Not only will there be those added options, the display in the status bar will give visual cues as to the state of the autosaves and backups. In other words you can instantly tell whether the options are turned on and if so have backups been saved.
It sounds super shiny, helpful & elegant, but I don’t have any real input at this time.
Don’t know if it’s super shiny… lol
But it would be more helpful and at least give a user more than an all or none option.
Aaah, ok. Now I get it (Better late than never ) Yes, I think those check boxes will work nicely.
Yeah… I probably could have explained it better, and of course a pic would have made even more sense.
I’m thinking that the list should all be checked as a default, and a user can uncheck those files not to restore. That way the default acts like it currently does with all files being restored. Or more specifically as far as the autosave (A) files maybe we should refer to it as “recovered” to differentiate between restoring a versioned autosave or backup file?
I went ahead and created a new “recover” dialog… yes it does work nicely/
Again… this dialog will pop up when (re)starting the Seamly2D app IF there were any patterns open with unsaved changes due to either some sort of crash OR if the pattern was closed without saving. It will display 5 files, and if necessary scrollbars will appear if there are more files or if the path name is really long.
Another addition I made (if the build is made with Qt 5.15.0 or newer) is when ANY of the A, V or B files are deleted by the app - either when removing an xxx.val.autosave file when a pattern is saved, when removing older versioned or backups when the max number limit has been reached, or when a user intentionally deletes a file in the Restore dialog via the context menu - the file is moved to the trash bin rather than being permanently removed. This is just one last chance to recover a pattern. Short of an act of God, there should be no reason to ever loose a pattern.