New backup feature

Not to be lippy, but don’t those seem like they’re going a bit out on a limb? LOL

However, this question has been raised before. I’m pretty sure @slspencer posted some intended file extensions, but I’m having trouble finding them. I did find this post: Pattern & Measurement file name extentions - #4 by KeithFromCanada both of his suggestions were 4 character.

I think the thing isn’t so much that there’s no overlap with other filetypes, as that when looking in a Seamly/Valentina directory it’s obvious which one one is in?

However, here are my ideas

  • SBLK - Seamly (draft) block file - not found on file.org
  • BLOK - it’s a pattern drafting block - not found on file.org
  • S2B - Seamly2D block file - not found on file.org
  • S2M - Seamly2D measurement file - file.org says that it is currently used for a game

Anyway, that’s some thoughts for now. I just wish I could find the official plan

1 Like

I’ve dug deeper into the autosave, and besides finding out it’s a bit more involved due the code to recover from autosaved files - which there can be more than one of from a crash… I decided it’s easier to get a date and time stamp based on the locale rather than the “label” date and time format prefs. Or maybe just a few pref choices of locale, yyyy/mm/dd, mm/dd/yyyy.

1 Like

Made some headway implementing versioned autosaves… in the process reworked a couple of the pref dialogs to open up some real-estate.

Moved the Pattern Making System groupbox to the Pattern prefs dialog - where it should have been in the first place. In the process removed some more useless code that re-read the language dropdown and reloaded the translations files when the PMS was changed. ???

autosave.3

Added an Autosave groupbox for autosave prefs:

autosave4

So the new option is a checkbox to enable multiple (versioned) autosaves. Found a neat trick within Creator to generate the code to disable the Enable Autosave without having to go the radio button route which takes more overhead to handle. Also added a maximum number of autosaves spinbox, and a dropdown with 3 different formats for the date. Oh… BTW I fixed the interval setting which always reverts to 1, as the dialog never initializes the spinbox from the settings ini file.

And also added a new entry in the File Paths dialog as to where the autosaves are saved. The app will create a default path in the user/seamly2d folder if it’s not there when the app boots… just like all the other folders. Of course if you want things to remain the same, you can just set this the same as the “My Patterns”. Which IMO I’d like to get rid of the stupid “My” thing - it’s such an outdated lame Microsoft practice that just needs to go.

autosave2

So… now you can save a single autosave - like it currently functions, or save versioned autosaves with a date & time stamp inserted in the file name.

autosave1

Here I switched on the versioned autosave, then changed the date format… of course it had to be aug 8, where switching dd/mm & mm/dd is the same. LOL So now I just have to add code to handle the max number of autosaves, and to adjust the code to handle a crash recovery - assuming that the app would use the last autosave to try and recover.

1 Like

Wow! That’s a huge lot of things that you’ve done. Thank you very much :star_struck:

Hmmm… Yeah! I don’t mind, either way. Perhaps set the heading to “Personal Paths”, “Path Preferences” or “Preferential Paths” and then remove off the 'My" from the list? :slight_smile: I think that, since it is the Seamly2D program, it doesn’t need to be reiterated in that heading.

I always thought the MS “My” thing was contrived and over done… it’s outdated like “My Space”. It’s one thing if the app was referencing a Windows folder like “mydocuments”, but these are just labels in the dialog. At any rate, for the moment I left the My’s in there so as to not break more translations.

Update:

Was just checking LibreOffice as to how it handles autosave files and in the process checked the Prefs->Paths and the only path that uses “My” is “My Documents”… as it refers to a Windows folder. Which BTW, even MS doesn’t use “My” anymore with Windows 10.

libre

1 Like

Besides getting the limit on the max number of autosaves working … here’s what I have in mind to handle versioned autosaves so it takes some of the work out of restoring a pattern to any particular autosave.

Here’s several autosaves of the maleshirt.val pattern… with the date stamp & “(autosave)” text inserted in the filename.

auto1

One could go and find a file in the “autosave” path and open it up, rename the file, etc… but there can be an easier way:

Select File->Restore Version

auto2

a dialog pops up that lists the autosaved files:

auto3

Note that the date stamp & “(autosave)” have been removed from the filenames… select the version to restore and it will copy the versioned file to the old (crashed?) file and load it. Voila.

3 Likes

These are all really great, but we CAN use 4 chars for a file extension. These are available:

  • SMLY (Seamly2D)
  • SMME (SeamlyME) And I love these:
  • SBLK
  • BLOK !!! YAAAS!

So does anyone want a separate file extension for basic blocks? Import a .BLOK file then create a design (.SMLY) based on it :D. The Block (.BLOK) is immutable, the design (.SMLY) is changeable. We can implement the pattern making systems this way, to make it easier to use the patternmaking books.

1 Like

Those work for me. :slight_smile:

On the autosave front I’m looking at a dual approach… keep the existing single autosave file that is created at X interval for an unsaved pattern, which is cleared when the pattern is saved, and if there is a crash and the autosave file exists that the app attempts to recover. The other option would be keeping X number of versions autosave (maybe should be named filename(backup).val instead?), where the user could use on of those files to recover from… either in the event the autosave failed or they wish to ho back to an earlier version.

I’m debating which way to save versioned files… autosaving an unsaved pattern at the set interval OR saving a backup copy when a pattern is saved. I’m tending toward the later… which seems a little clearer. You could enable “Autosave” AND / OR enable “Backups”.

1 Like

:slight_smile: My ha’pennies worth…

If one disables the autosave until after the 1st save, then I’d suggest that one force a 1st save directly after creating a new pattern, because newbies won’t be concerned with saving until they’ve reached a point where they would like to exit or to start a new project, and anything can happen between the start & the save. I think the autosave and the backup should be 2 separate things and should both be active.

The autosave is a temporary file that gets written over with each save at whatever intervals and would be the file that is loaded directly after a crash to restore the work at the current point. If one were to keep a few back, then I think 3 or 5 would be sufficient.

While a backup is something one would manually create at a point where one has done so much work that losing any part of it would be terrible & should be versioned so that one could go back by restoring from a specific backup point. These could have an option to be kept and a user could manually delete any that they wish to delete, to overwrite a previous backup or to keep a certain number of previous backups and remove the oldest.

2 Likes

Well that presents an argument for having multiple autosaves. Which I can see. Myself I’ve been at this computer thing so long that ctrl-s are my most used keys. I just hit them often by habit without even thinking. In fact I just noticed the other day that the silicone keypad cover on my laptop has no color on the ctrl and S keys anymore.

Exactly.

Again… exactly. So given that the single autosave file and recover remains as is - with the exception that the file would be (temporarily) saved in the autosave / backup dir vs the pattern dir… the question is do we want to have multiple version autosave and / or backups? The only difference would be that the autosaves would be the last unsaved state, and the backups the last saved state. In terms of coding it’s no big deal either or both ways, and the size of any given xml pattern is so small that a 1/2 dozen copies (or so) of each is no big deal. And yes… the files would delete first in first out… based on if the max number is reached.

If we save both I would use the formats:

filename_[date-time](autosave).val or .vit

filename_[date-time](backup).val or .vit

Then with the recover menu item it would show a list of both types, and you could choose to say restore the last saved file or the last unsaved file.

2 Likes

Yip! I think this will make me very happy :slight_smile:

Thank you very much.

I changed up the prefs to accommodate autosaves & backups, and in the process rearranged the “Configuration” page into 3 tabs to provide more space. Also fixed a kinda of dumb & confusing setting “Reset Warnings”. I broke it up into the constituent settings so it’s clear(er) what the settings do.

So in the “File handling” tab there will be the settings for the autosave and backups. To cover all the bases, you can select none, one or any combo of the 3 ways to produce backups to recover from.

pref2

The language settings will move to the “Language” tab. pref3

And the last “General” tab contains the rest of the Configuration settings. The pattern editing warnings refer to the “Do not ask again” checkmarks in the associated dialogs. So now, instead of resetting both settings to “True” that is enabled, you can (re)set either of the settings independently in the Preferences.

pref1

confirmdelete

confirmformat

2 Likes

Well… I’m going to improve some code and the restore behavior for the simple autosave.

Currently the autosave behavior is that an .autosave file is created whenever a pattern has unsaved changes and the timer interval has elapsed. When the autosave file is written, a list of “restore” files is retrieved from the settings file, the current autosaved file added to the list, and it’s stored back. When a pattern is saved the autosave is deleted, the restore file list is retrieved, the autosaved file removed from the list, and the list stored back to the settings. This is done for every pattern file that is opened. The restore file list is loaded whenever the app is started… in the event of a crash, the list “should” contain all the patterns open at the time of the crash… where the app runs through a loop and attempts to open each one. Also the app will remove an autosave file, and from the restore list whenever the app is closed, regardless if the pattern was saved or not.

So…

  1. The logic to store / retrieve and keep track of autosaved files is rather excessive.

  2. In the event a user accidently closes the app and ignores the warning to save the pattern before closing - any unsaved changes are gone.

Since I plan to switch to using a “backup” folder to store autosaved & backup files, there’s no need to keep track of the autosaved files in the ini settings file… we can just look at the dir to see what filename.val.autosave’s there are that need to be restored. Mo code gone. :slight_smile:

By simply not deleting any autosaved files on closing the app, it leaves them in the backup folder, and if you start the app up any files you failed to save before closing the app will be restored. :slight_smile:

Which brings me to mentioning one slight limitation in the behavior in the versioned autosave & backups I’m looking at. Lets assume we enable the versioned autosaves and the max number of autosaves is set to 3… and we open the pattern curly.val… after 1min we have something like this in the backup folder:

curly.val.autosave
curly_201210820_12:13(autosave).val

after 3 mintues:
curly.val.autosave
curly_201210820_12:15:00(autosave).val
curly_201210820_12:14:00(autosave).val
curly_201210820_12:13:00(autosave).val

Then we open larry.val and we have:
curly.val.autosave
larry.val.autosave
larry_201210820_12:16:00(autosave).val
curly_201210820_12:14:00(autosave).val
curly_201210820_12:13:00(autosave).val

Then we open mo.val and we have:
curly.val.autosave
larry.val.autosave
mo.val.autosave
mo_201210820_12:20:00(autosave).val
larry_201210820_12:19:00(autosave).val
curly_201210820_12:18:00(autosave).val

Then we open shemp.val and we have:
curly.val.autosave
larry.val.autosave
mo.val.autosave
shemp.val.autosave
shemp_201210820_12:21:00(autosave).val
mo_201210820_12:20:00(autosave).val
larry_201210820_12:19:00(autosave).val

OOPS… no more curly versioned autosave file!

While not the end of the world, as

  1. A user could always increase the max number of autosaves
  2. Probably not that often a user will have that many open patterns at any given time.

One possible solution I could add is to warn the user that the number of open files will exceed the number of versioned autosaves and / or backups - with the option to automatically increment the max number. Thoughts?

As a related issue… what does everyone think about having the option to automatically open the last used pattern file?

1 Like

Is this not because nothing has changed on the curly file, since the person was now working on shemp, even if the file was open?

No, I think that one should remember that the saves are the recovery files if there is a crash and are done automatically, while the backups are done manually at certain points of development where one may want to go back to that point at a later time.

The only purpose, that I can see, in multiple autosaves is, after a crash, if the latest one has become corrupt and cannot be opened, then one could try to recover the previous one.

No, I think that having it on the list of recently used patterns is enough :slight_smile:

In practice it could be anyone of the files to fall off the list, depending on timing and unsaved changes.

Exactly… but hypothetically if a user opens up more than the max number of autosaves set in the prefs, one of the patterns will not even have 1 versioned autosave.

Just figured I’d ask. The video editor I use has this feature, but then with editing video it can be common to be editing a project for days or weeks. Also it’s common for me to be opening a pattern dozens of times in an evening while testing / debugging - where even selecting the last used file gets tedious… or I’m just getting old and lazy. LOL

1 Like

I think, before you go with what I think, rather wait for a few others to give their opinions. Sometimes, I help people on here, so I don’t want to load their pattern, so I’m a special case :slight_smile: Although, I can see the use of it.

I’m on the fence… with the video editor sometimes if you’re just wanting to start the app with a new project, it becomes just the opposite, where now you have to close (or cancel the load) the last project. I was just thinking of the feature, as it would deal with the same part of the code for opening / restoring a pattern file.

1 Like

If you’re busy with it now, and would like to include it, then I think add the option to do it in the preferences. Then a person can choose if they’d like it turned on or off, or to ask when opening Seamly whether you would like to open the last used pattern.

1 Like

The preference is a given… but I like the idea of asking to open the last pattern IF the feature is enabled. :slight_smile:

3 Likes

Unlike with video files, Seamly files are resource-light, so it won’t be a problem to wait for the last used file to load before opening a different file. However, that does end up with two files open, only one of which is wanted. So the solution as stated, to have a popup asking whether to open the last used file, is good.

Another possible solution would be to ask if the file should be opened upon loading as a closing dialog. But I think that the opening dialog is probably better.

on the other note, would it not be possible to have three autosaves per file?

1 Like