Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Autosave by default, please #170

Open
SonyStone opened this issue Oct 1, 2023 · 14 comments
Open

Autosave by default, please #170

SonyStone opened this issue Oct 1, 2023 · 14 comments

Comments

@SonyStone
Copy link

SonyStone commented Oct 1, 2023

Is your feature request related to a problem? Please describe

I just lost hours of work again. Why isn't this the default? Even photoshop has autosave by default.

Describe the solution you'd like

Do autosave by default, please

@SonyStone SonyStone changed the title Auto save pls Auto save please Oct 1, 2023
@SonyStone SonyStone changed the title Auto save please Autosave please Oct 1, 2023
@SonyStone SonyStone changed the title Autosave please Autosave by default, please Oct 1, 2023
@RodneyBaker
Copy link
Collaborator

RodneyBaker commented Oct 1, 2023

Thanks for your request @SonyStone and very sorry to hear of your loss.

The short answer to the question of why Autosave isn't on by default is: Autosave is evil.
The long answer is... longer.

Prior discussions have ruled out having Autosave on by default as it creates more problems than is resolves.
This doesn't mean that decision can't change but you'll need to provide very good justification for that change.

General rationale:
Rather than rely on autosave it would be more optimal to resolve the problem(s) causing the loss of work in the first place.
Any information you can supply regarding what led to your loss will be useful toward resolving those problems.

@DarrenTAnims
Copy link
Collaborator

You can turn auto-save on, if you want to, when you start a project or change this setting part way through, if you prefer.
But manually saving will always be best. But it's good advice, when using any program, to save regularly. You should never leave yourself in a situation where you can lose hours of work. Anything could happen at any time, crashes, power cuts, children tripping over cables. Get used to smashing that save button.

@Bracket-H
Copy link

Bracket-H commented Oct 2, 2023

Smash that save button, indeed.
Opentoonz has many moving parts, autosave, even if it wasn't so problematic, still doesn't really add that much value.

If you consider OT just a drawing program, and only care about the images, then yes I guess autosaving would be ok and not having it would sting a little, but...it's not just a drawing program.

It could be autosaving now, and then you keyframe some things, change some palettes, fiddle with FX, write some expressions maybe, rearrange some sub sheets, retime this section, retime that sec...crash.

And now you get to do that all over again!
There's so much you can be doing in OT that even an autosave 5 minutes ago will still feel like a crushing defeat.

Save. Save. Save. Save. Save.
Bind it to a hotkey, buy a foot pedal that is bound to saving if need be, don't rely on autosave even if you enable it.
Simply imagine autosave doesn't exist, and it really shouldn't, hardware is good enough, even solid state drives, to handle repeated writes in a short time.

@Bracket-H
Copy link

Seriously...hours of work of you not caring to save it?
You worked that hard in two hours but couldn't find it in you to even go the hard way of clicking the menu, and going into the save section there?

C'mon...I know victim shaming isn't good form but...c'mon...
You could have done a little bit of arm movement after one hour at least...

@SonyStone
Copy link
Author

Seriously...hours of work of you not caring to save it?
You worked that hard in two hours but couldn't find it in you to even go the hard way of clicking the menu, and going into the save section there?

C'mon...I know victim shaming isn't good form but...c'mon...
You could have done a little bit of arm movement after one hour at least...

I'm too used to programs where you do not need to save every five minutes.

@Bracket-H
Copy link

Bracket-H commented Oct 3, 2023

Well, OT is a program where you should save every minute :P hahahaa...

But seriously, autosave in OT is not very helpful, unless you only do like, one simple thing at a time.
Still, I'd say it's a good habit to save. Trusting machines ...well, they like to betray.
I use Steam, it has auto cloud saving and that burned me a few times as well.

But yeah it has autosaves, they just need to be enabled in the option. I have not used them in ages... too many issues.
Again, too many moving parts...and hitting control + s fixes pretty much all of them.

P.S.:
I'm not an asskissing OT shill, though. In fact, I usually really loathe it when someone comes in and makes some excuse for something really asinine that should be fixed.
It really is just ...not a good system for OT, maybe it could be one one day but it's so much to implement ...for something the user could just do.

It's not like LMMS where on default setting playing a simple three pitch chord makes the audio clip...
Or Hydrogen where the midi output for a drum part needs a sample to even work even if you don't want or need sampling output.
Or Carla where the breath midi controller is hardcoded to changing the mix of the first midi in routing thing or something.
Or back in the days where PulseAudio on Linux had this auto gain option that would blow out speakers and/or human ears by putting the volume to the max if some application that wants it that way is launched.

In this case...the system exists, it sort of does what its needed its just...not actually that helpful.
I'm not trying to be that kinda guy I just honestly think that manual saving is something a user can reasonably do, considering how complex and "pro" this software is.
(It's aimed at studio usage after all, where its not just one user, juggling that has more nuance than a single user image editing software...)

@RodneyBaker
Copy link
Collaborator

RodneyBaker commented Nov 7, 2023

For my part I don't save often, I just try to save any time I make a major change to a scene/project.

I'm not quite sure how to classify this request.

On the one hand, there are known issues with using Autosave and apparently the more users rely on it the worse experience they have. Not quite sure what to do about that short of do a deep look into the Autosave and History features with an eye to update and optimize those to the point where they work really well and seldom have issue.

On the other hand, the likelyhood of Autosave being set to on by default is not likely.
Too many users don't want to use Autosave at all much less have it turned on by default.

I believe we all get that there are problems with stability, loss of data etc.
Use of Autosave to address those problem at this point in time... until Autosave and the Undo/History processes can be perfected... just isn't the ideal solution.

If we had a 'will not implement' label that label would likely be applied to this request.
This not to say it never would be but certainly not at this time.

@Bracket-H
Copy link

Bracket-H commented Nov 7, 2023

I see it like this:
Opentoonz is an animation program, a 2D animation program.
2D animation, even computer aided, is a laborious process.
The time/diligence it takes to manually save is miniscule compared to the overall task of creating the animation.

Especially the more intricate things are.
Do you know the Slackware Linux distro? Slackware is a linux distribution that completely lacks automatic software package dependency resolution. It has to be done by the user.

This means that it's perfectly possible to even download an official package, but if you don't also download or compile its dependencies, then it will not work.

This part of Slackware gets heavy critique all the time, especially since the usual solution for the official software repo is to install the ENTIRE DISTRO set, because then all dependencies for the first party software is met.

This is then called "Bloat" by detractors (even though it only takes up harddrive space and not runtime memory or cpu stuff), and many people want "minimal systems".

But here is the thing, the more minimal you make the system, the less dependencies one needs, logically, right?
So the workload gets decreased, making this critique point less and less relevant...

(this is the equivalent of only making short, simple animations and not having autosave)

However, of course, there's the issue of a big feature filled version of the distro, with many packages, including third party ones (like Opentoonz)

Many people still use slackware, myself included, despite this glaring oversight, you know why?

Because:
1.) Harddrive space has been pretty cheap for over a decade, and even then...2-3 GB was not that much
2.) You NEVER get dependency automation failures because the package maintainer messed up
3.) You NEVER get extraneous dependencies (which would also fall under 'harddrive bloat' aka no bloat at all, but still, it also happens under automated designs)

2 and 3 are the equivalent for OT, you don't get autosave failures during full manual saving, and... here is where the analogy will limp a bit, but will still be applicable.

Software is not changed much, it gets updated often but not CHANGED, you don't swap out sed for awk every day, you don't swap out opentoonz for synfig studio every day, you don't swap out krita for gimp or mypaint every day.

And when you do change softwares, its a little bit of effort, sure...and maybe a pain, but dependencies, even completely third party where the Slackware user must do everything... are listed on the project pages.
Because open source software wants to be compilable...so...yeah.

And that then can be scripted, too. (In Slackware this is a buildscript) this is where the analogy fails becaus that's automation, and I'm trying to make a case for not automation.

And that case is just...it's al fun and games with automated package system until they break.
Then it can be an IMMENSE hassle for the user to deal with that, especially if they blindly and ignorance fosteringly relied on it all, and have no idea what to do.

I...sometimes have some frustration too, but I will never EVER switch from slackware in any foreseeable future because...
It works in the end, the hassle is miniscule or a lazy bastard like myself wouldn't use it.
Overall, it is less of a pain, less of a pain in theory/worst case, and in practice.

Same with manual saving in animation, the more complex it is, the less of a price manual saving is, and the more you get paid off by removing autosave shenanigans.

So, in conclusion I would say that...classifying this request as "human diligence and average intelligence" is the best fix for it, believe in the capability of humanity.

But that is only a suggestion and a perspective of this one user here, but if you rounded up all the Slackware users, they'd tell you the same, from blind user sheep who just wants to be edgy or hipster for using this prehistoric distro, to the people who know why its actually good, to the big brain gods who actually work on maintaining the distro themselves.

They'd all agree.

P.S.: And the package manager is actually pretty good, it just doesn't do dependency resolution, but it detects shared files, deals with them intelligently, is plaintext in itself (like all slackware system tools, they're all plaintext scripts)
And it imparts a sense of knowledge on how to deal with Linux software management.

It's incredibly hard to brick my system, because it's not automated in those ways, and because its not automated, I also have now, long long ago to a second nature aquired the skill for it.

And I'm not a rocket scientist. I love this system, and likewise, once I stopped using autosave for OT, I don't miss it.
At all, I have not gotten mad at OT in ages. Not on that front anyway =P

Using vectors will probably be a low blood pressure cure for the time being... but not saving.

@RodneyBaker
Copy link
Collaborator

.classifying this request as "human diligence and average intelligence" is the best fix for it

I can't find that label but I'll apply 'known issue' and we can pretend it says that. ;)

@Bracket-H
Copy link

Haha, well, I just ... I don't wanna be a shill, and I don't want to "excuse the OT development team from doing work and improving the software"

If one day autosave is some sort of AI augmented overmind that has the least amount of movable parts frustration (autosave just saved, but then you changed a palette or something which the autosaved image relies on, etc)
Then great.

But otherwise, manual is fine, even when "in the zone"

After all, even in the zone, one is operating a mechanical/electrical device.
Which includes even subtle things like lifting a stylus or moving the mouse and putting it down again, some sort of 'control procedure' is done.

And those are not that different to 'in the flow' hitting control S to save to ones current expectations, rather than surprise.

Especially if the 'flow' includes rotating the canvas, flipping the image, and other 'more complicated stunts'.
Again, I get it, I don't want to be mean, a shill, or whatever. I truly am saying/writing all this in good faith and well meaning.
The price to pay for control S, even bound to esotheric means, like a foot pedal, or a command word via mic... can save so much trouble and is such a low price overall...

@RodneyBaker
Copy link
Collaborator

Rather than close this report I will transfer it over to Opentoonz Docs where at least it will be recorded that some users wish to have Autosave on by default.

@RodneyBaker RodneyBaker transferred this issue from opentoonz/opentoonz Nov 19, 2023
@RodneyBaker
Copy link
Collaborator

As there are no plans to implement this request we should look for alternatives to implementation and/or workarounds which meeet the intent or need of this request.

Currently, the main options are to immediately set Autosave to 'On' after installation and (for good measure although likely not necessary) invoke the 'Set As Default' option in the menu. This should keep autosave on to fill the need until that setting is overwritten.

The other alternative as with many other customizations that are not expected to be implemented as default is to build Opentoonz from source code adjusting the setting as needed. As a community we should work to improve the process by which users can build locally not only to allow for maximum customization and resolution of personal preferences but also to improve the knowledge base and potential for future development.

Documentation can and very likely should be updated to capture the broad scope of the use of Autosave with a focus on how best to set its options and for optimal usage (if/where needed).

Best practices with respect to autosave features in software should be reviewed as that can, at least theoretically, resolve any currently experienced issues with the feature and address the needs of all Opentoonz users.

Related considerations:
The process of saving to disk itself presents a challenge for optimization, security of data and performance.
Taking a deep look into the broader process of how data is saved, stored and recovered should result in improvement in these areas.

@Bracket-H
Copy link

I'm still on camp "just bind save all to a shortcut (including physical things like a streamer deck or wacom remote) that's easily hit.

I don't know how to phrase the following properly but, I think OT is simply too odd for mainstream lazyness like "let the computer decide the saving I don't wanna save manually"

I mean ...it doesn't even have a way to stay in a level for drawing, and have an external 'layout' behind it. The only way to draw into a level with a background or layout for orientation is to use the xsheet or the timeline and draw in into the viewer like that.
But not drawing into a level directly. Hell, you can't even have levels accessible without exposing at least one frame into the xsheet/timeline.

And I guess that was never needed in the Ghibli/Japanimation (paper to digital ) pipeline.
That, to me is a more alien approach compared to contemporary expectations than a wonky, but mostly working autosave.

(my workaround is copy pasting layouts into levels, and 'pinned oninion skin' reference it in the cels that are actually intended to be exposed.
But that's another can of worms.

Having to hit control S ....is so much easier than wrestling with THAT kind of thing.

And while I am a big proponent of quality of life... OT, again, is advertised (and regarded as) industry standard software, and those tend come with quirks.

Campaign Cartographer for example, it's super pwoerful for map creation (like. overland maps, like a real map or fantasy)
But it's tied to a prehistoric, iffy to use cad backend. It will probably never be modernized, but if you play along with it's awful ways, your reward is tippy top maps. They look really really good.

..just save manually after every significant action you on't want to lose progress on. OT is such a prickly chestnut, even a 5 minute interval of save automation might not safety net something that was a pain to draw, color match, composite, configure, etc.
It's animation, hitting a key is NOTHING compared to the overall workflow, I think I'm convinced of this that I want autosave not even to be an option at all.

I realize peer pressure is bearing down on OT too. It's just the sad state of affairs we all live in. Just like how control x and control v and all that are mainstream instead of 'modal controls' like in the vi(m) text editor.
Now the vast majority of programs are chord based, instead of simple key sequences that are entered during a certain mode of operation.

In fact, the modal way is so good that many softwares have had to implement it around the back with 'context' or 'which work thing in the application is currently focused'.
So let's say control + p does one thing when a certain panel is focused, and another thing if another panel is focused.

That is modal too, the soul craves it, but it's denied due to...I dunno, some sort of marketing. But yeah.
It's just one key chord ;-; and it gives full autonomy and emancipation and sovereignity over the process of securing data for the whole thing.
No guesswork where the autosave timer is.
No guesswork where the autosaved files are (although OT is preetty good with this and doesn't send it to the shadowrealm 10 layers deep into some local cache 'safespace')

Ah... taking matters into ones own hands isn't always baaaaad.

@RodneyBaker
Copy link
Collaborator

RodneyBaker commented Sep 22, 2024

Users experiencing issues with Autosave should definitely be using a nightly release of Opentoonz as it contains some fixes for Autosave (as ported from the Tahoma2D fork). Namely (from @manongjohn):

While reviewing a reported issue, I noticed there is a potential for overlapping save operations under certain scenarios which could potentially result in file corruption. Additionally, the report suggests an undo operation was performed while an autosave was in progress. This could cause a crash when it tries to access something that may no longer exist.

I've added logic to internally flag when a save is in progress so that any additional calls to save while actively saving will wait until the flag is cleared.

Scenarios that should be covered by this fix

Timed autosave + suspended autosave due to active drawing or something
Timed autosave + manual save by user
Timed autosave + Undo/Redo
NOTE: It's hard to duplicate overlapping saving issues naturally. I mostly regression tested for normal saving and autosaving operations as well as a simple saving error (file locked) and ensuring I didn't completely freeze up.```

Any nightly release after January 2024 should contain that Autosave related update.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants