Prompt user to save scene as soon as it is created

[morevnaproject]

As pointed in #3259 (comment), working on unsaved scene can lead to troubles.

It would be nice if OpenToonz ask to save scene somewhere at the moment when it is created.

[RodneyBaker]

Initial scenes (created via startup popup) are now saved upon creation.
REF: #3064 which addresses #3034

I do think Opentoonz should suggest a name for scenes such as 'untitled.0001.tnz' although there might be an issue with 'sequential scenes' as they really aren't a consideration. Such an offering for levels however would help instruct users in the ideal filenaming convention for sequential images. Perhaps for Scenes it could just be 'untitled0001.tnz' or even 'untitled.tnz'. It would be optimal if Opentoonz tested for files named 'untitled' and then suggested the next available one.

Aside: For quick sketching, I know all files are date/time stamped but I find myself wishing scenes/levels could take the name of the current date and time for that workflow.

I'll stop there before I hurt myself thinking about such things.

[morevnaproject]

Oh, sorry, I haven't clarified.

I was talking about the case when scene is created via "File" -> "New scene..." command (or Ctrl+N).

When scene is created via Startup Popup everything is alright. ^__^

[RodneyBaker]

Excellent point.
The Scenes must be getting saved somewhere... even if only in cache... because I do see the scene name appearing in the toolbar (mine currently reading as 'untitled19'.

[morevnaproject]

The worst thing is that it can lead to data loss:
if I import images into unsaved scene, then save, close and re-open -> images get lost after that.

[RodneyBaker]

if I import images into unsaved scene, then save, close and re-open -> images get lost after that.

This is the part that concerns me as it:

1. Shouldn't happen.
2. Suggests that saving the Scene as soon as it is created will not address the underlying problem.

An issue here remains that in the situation you describe a typical 'Save Scene' will only save the Scene whereas a 'Save All' will save both the Scene and the levels/images inside the Project.

Perhaps the 'Save Scene' option needs to be reworded 'Save Scene only' and 'Save All' needs to be put higher in the menu than 'Save Scene Only'.

This is a very old problem that was mostly remedied by developers adjusting the save process to empahasize Saving All files in a project. Perhaps that effort didn't quite go far enough.

Aside: I do think that the current 'Export Scene' option... which is a Right Click option in the Browser when right clicking on a .tnz scene file... should be updated, developed and made more prominent in the menu as its usage would help in instances where the user wishes to store, archive or share the entire contents of a Project file. It would be optimal to have an option to zip up a 'project' into a single compressed file. This compressed zip file then could officially be known as a 'project file'. Give it a .project or .tprj extension that can be: 1) recognized by Opentoonz as a project 2) renamed as .zip at any time for normal usage as compressed collection of files. Development efforts could then be made to optimize the use and processing of that project file to benefit of all.

[morevnaproject]

Ah, sorry, I wasn't clear enough.
When I said "save" in my previous message I was meaning "save all".
I have data loss even after "save all" command, if I do something on unsaved scene. ^__^

... This compressed zip file then could officially be known as a 'project file'. ...

This is a great idea, but I think this deserves a separate discussion.
From my experience I can say that implementing loading of ZIP files is not that easy as it seems on first sight. My team made an attempt to implement the same for Synfig and that was not easy and the feature is still remains incomplete. The main problem is that ZIP file is not the same as filesystem - you cannot write and read there in the same way. And another bunch of problems comes when you want to reference assets from zip file. I do not say this is impossible, but this just be more complicated than it seems first. ^__^

[shun-iwasawa]

In the comment I just meant to notify that the Scene Folder Aliases won't work on the untitled scenes.
Well, I think we can have some warning popup if the Scene Folder Aliases option is activated AND user tries to create / import levels into the untitled scene in order to avoid the files to be saved in unwanted location.

Please note that it’s not always the case that the scene must be getting saved. For ink&paint workflow, they would like to modify only levels but won't save scenes.

if I import images into unsaved scene, then save, close and re-open -> images get lost after that.

Please let me know about this problem in detail..
Are you activating Append $scenepath to +drawings option in the project settings?
I doubt if this option works properly as it has been left as-is from Toonz Harlequin.

[morevnaproject]

For ink&paint workflow, they would like to modify only levels but won't save scenes.

This is interesting, I wasn't aware about this possibility! ^__^

Are you activating Append $scenepath to +drawings option in the project settings?

Exactly! Yes, I have this option activated for all projects, as this allows separate assets for each scene.

It works perfectly when scene is saved. But when it is not saved, then (I guess) we hit the same problem as with $scenefolder - the variable $scenepath is undefined. And this is why data gets lost.

[morevnaproject]

For ink&paint workflow, they would like to modify only levels but won't save scenes.

It works perfectly when scene is saved. But when it is not saved, then we hit the same problem as with $scenefolder - the variable $scenepath is undefined

So, my suggestion:

When scene is created, OpenToonz should prompt user to save scene only if project uses $scenepath variable or Path Alias Priority set to Scene Folder Alias ($scenefolder) in preferences.

How about that? ^__^

[gab3d]

Please don't take what I'm about to say as a personal judgement about anyone but, besides the understandable wish from some users to make changes to various application behaviors to correct what are perceived as flaws or lackings, I'm often seeing that those users suggesting changes have not dedicated the required amount of time to fully understand the base thinking behind the original Toonz design in that area.
And while I'm all in for new, previously unthought of, features and bug fixes of any kind, I feel sometimes in our eagerness for solutions to our very problems, we are overlooking some well thought out workflows developed through the years.

So my recomendation would be, that before we try to raise a discussion or report some lacking feature in the software, we made ourselves assured that we've thoroughly explored and understood how the software was intended to give solution to this area or feature, and then if we still see problems or improvements to be made there, then we do greenlight our feelings and propositions to the rest.

I say this, because I've seen repeatedly that the first conclusion a good deal of users arrive at, very fast, when something is not working as they expect is that the software is simply defective, and that's it.
I think that in the long years this software has existed, for sure the developers have had time to think about and work on how to approach and resolve almost all of the basic features and workflows for the most common use cases in client studios.

So, if admitedly there's still a lot to tweak and fix, and a road to travel to make the software more user friendly for small studios and independent users, as well as new features to be included, I think it'd be a good thing for us all to respect the previous work by just trying to be fully aware of the actual possibilities and abilities of the current functionalities, before suggesting to completely drop or replace them in favor of what, to me, at this moment in my understanding, it appears as a great idea.

Just that.
Thanks for reading this far...

[Lovewyrm]

While I have moved on from OT, that point was something I did want to put into the open.
Hence that (controversial) thread I made back then. You know "should OT be marketed as a general animation package" (or something like that.)

But I suppose I was too abrasive with my angle :p
It's true though, people expect "wow professinal tool" when it means very little.

Toonz could have always been used just to time some rough pencil tests, and it would still qualify for "used by Ghibli in movie production".

I'm glad it's finally getting through.

[morevnaproject]

@gab3d So, do you think this is normal behavior when user looses his data? ^__^

[gab3d]

@morevnaproject
As you, I teach animation since a long time ago, using many different programs.
So I'd say if you're talking about students losing data because of a lack of knowledge of the program (I'm sure we both have seen this happen too many times), then I would consider the lacking leading to that data loss is not in the program, but in the person not knowing how to correctly use it.

If, on the other hand, you're talking about a knowledgeable user who loses his data because a program bug, then this is obviously not normal, nor desirable.
In name of what kind of user are you speaking here? to put things clear... 🤔

So, do you think this is normal behavior when user looses his data?

Still, in any case, how that's the conclusion you arrived at from what I've pointed out, frankly escapes me... 🤦

[manongjohn]

I haven't followed the entire thread but thought would give my 2 cents...

Personally I would be annoyed if I had to save a scene at the moment of creation. I often open OT just to doodle or practice animating something and don't care to save scene (and sometimes level too). So I disagree that a scene should be prompted to save on initial creation. I've not used any software that prompted me to save before I even did anything in it.

I understand you are trying to prevent loss of work, but beyond a crash or some strange bug, the user would/should know when to save work in progress.

I think 1 issue that has caused drawing loss is when people use Save Scene expecting it to save level. I think if Save Scene is used and there are unsaved levels, it should immediately notify and prompt to either save just scene or save levels too with option to remember answer for future save scene actions.

As for the use of$scenepath...I've seen strange cases where the level was saved with untitled## as part of the path but the scene had a real name. I'm not entirely sure how that happened, though it did save in the scene file correctly.

I have been noticing more reports of things missing after reopening scene even after reportedly using Save All. I think there is a saving bug somewhere but rather difficult to determine where.

[gab3d]

@manongjohn
I agree on finding annoying being forced to save a scene upfront.

I also strongly support the Save Scene bahavior you propose. 👍

[morevnaproject]

So, do you think this is normal behavior when user looses his data?

Still, in any case, how that's the conclusion you arrived at from what I've pointed out, frankly escapes me... facepalm

Sorry, probably, I wasn't clear enough.

I have identified the problem in earlier comment -
#3323 (comment)

As for the use of $scenepath...I've seen strange cases where the level was saved with untitled## as part of the path but the scene had a real name. I'm not entirely sure how that happened, though it did save in the scene file correctly.

Here is detailed illustration of this problem in video - https://youtu.be/MKpKuR7rl90

I am also attaching sample project, which you can use to reproduce the problem -
sample.zip

Just do the following:

1. Download and unpack sample project.
2. Open scene "main.tnz" from sample project
3. Create new scene
4. Import image (make sure to choose "Import" instead of "Load").
5. Save project ("File" -> "Save All"). Name scene as "bug".
6. Close OpenToonz
7. Start OpenToonz again and open "bug" scene.
8. Result: image is lost.

The problem is because project configuration uses $scenepath for extras . Because of this, OpenToonz do not know where to save imported image when the project name is undefined yet.

So I'd say if you're talking about students losing data because of a lack of knowledge of the program

No, I am talking about me loosing data regularly because I forget to save scene right after its creation. ^__^

So, the story of this issue:

• I have hit that problem with data loss (described above).
• I started to investigate why this happens and found that it is because $scenepath is undefined.
• I started to think about solution how to avoid data loss and my idea was that easiest way is to save scene when it is created. So I proposed this issue (see initial comment)
• @shun-iwasawa pointed out that there are certain situations, when artist do not wants to save scene.
• So, I modified my proposal, to prompt saving scene only when project configuration involves $scenepath or $scenefolder

If there are any other ideas, which can solve initial problem, then I will be happy to hear them. ^__^

Again, my initial intention for that issue was not to "break things" or "just make it work differently".
My intention was to avoid data loss. Technically I have enough coding skills to solve this problem by myself and merge it into Morevna Edition, but I brought the issue here for discussion to brainstorm and hear opinion of the artists with a good knowledge of the application. ^__^

[manongjohn]

Great. I'm glad you found the cause of that problem. Rather than reengineer how users should be saving things because of an obvious bug, I think fixing the problem of the empty variable is what is needed. Why is it empty when you are saving is the real issue.

The issues of work loss that i've seen seem to stem from a bug in the saving process, not saving often and crashing, or a misunderstanding of what Save Scene actually means. Forcing a save at creation won't fix these causes.

I think the solution you proposed is unnecessary.

[morevnaproject]

I think the solution you proposed is unnecessary.

Well, I hope so. But the problem is that project is configured to store all images in scenes/SCENE_NAME/extras. Where SCENE_NAME is... well scene name.

So, if scene is not saved yet, then its name is unknown. So, the question: where OT will store bitmap image when I import it? (see image import at step 4, when project is not saved yet)

[manongjohn]

If the scene name is untitled* or unknown, it should be prompting for scene name to be saved. I tried to recreate the "untitled" scene path when saving a level but whenever I tried to save without it, it did prompt me for a scene name. Seems there is a bug somewhere, where it should be prompting for a scene name but it isn't. Maybe autosave is bypassing that check and it shouldn't or maybe shouldn't autosave unless a scene has already been saved once?

[gab3d]

@manongjohn
well, I think autosave should always save if it's activated, it's the main purpose of its existence.

when scene is yet unsaved, it should save things assuming a default path for that case.
when user saves the scene for the first time it should either move all the autosaved files to the proper path (preferable, more secure, but slow?) or delete them (at least just for not having infinite amounts of garbage in that path).

[manongjohn]

@gab3d Agreed.

It appears when autosave kicks in, if you have not saved it yet, it will pop up the save dialog so you can give it a name, so I don't think it's an issue with autosave.

@morevnaproject The behavior of Import images into an unsaved scene appears to be different if you are using $scenepath or not. If not used, it imports it directly into the current Project, say +extras. If $scenepath is used, it loads it into cache directory instead. The problem appears to be when you save it from cache. The folder +extras\untitled## is created in the Project folder first but the image fails to copy from the cache folder to that folder, which is likely the bug. What might be happening is it tries to copy it to +extras\newscene instead but that folder was not created. The untitled## one was created. It may be failing to copy and not throwing errors. Since it thinks it copied it, it deletes the cached version leading to image loss. We've seen this behavior before. I corrected it in another situation.

In my opinion, should always import directly into the current Project, even if the folder is named +extras\untitled##. Keep in mind, when you create a new level with $scenepath turned on, it asks you to create the level file and the path defaults to +extras\untitled## . It will save that way, even in the scene file when you finally save the scene.

[RodneyBaker]

This is slightly related to this issue...

For all of Opentoonz usage of the temporary filename of 'untitled##' I see very few instances where files actually get saved with that name. It seems the reason for this is that although as scene or level might temporarily be given the name of 'untitled##' that temp name is not populated in the save dialogs for scene or levels (which are presented as blank without any name).

I personally would be more than happy if the save dialogs allow files to be prepopulated with the temp filename and therefore more easily saved as 'untitled' followed by a number.

[RodneyBaker]

I was under the impression scene files are now saved even upon creation via File menu.
We need to validate this.

[janimatic]

hello everyone!
are you still considering this bug should be fixed?
I can't imagine working on a movie without $scenepath (levels with name conflict between shots would be unmanageable)
Creating a new scene is the normal behavior to create a new shot (ok, i could save scen before, but in creation i don't always now the context before starting drawing).
Like i mentioned in tahoma's bug report tahoma2d/tahoma2d#1384, i suggest restoring ressource old file path after save scene/save all (or create a new SceneRessource member variable m_originalPath if m_oldPath is already messed up / corrupted with path routines).
What do you think about it ?
Thank you!
cheers
Julien