LoadLevel > save all

[janimatic]

hello everyone!
Reviving the old issue....
opentoonz/opentoonz#3323
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 (and copy from it in /extras/$scenepath/foo.bar to update the level's 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

Originally posted by @janimatic in opentoonz/opentoonz#3323 (comment)

[RodneyBaker]

@janimatic Thanks for the report.
I (personally) don't quite follow all of the problem or proposed solution but hopefully John (@manongjohn at Tahoma2D) and others (such as @shun-iwasawa) will.

It may be the problem just needs to be restated (?)
Not sure but I didn't want you to think your report was being ignored.

[manongjohn]

Personally i dont think a scene (or level) should be saved immediately on creation. For anyone that may be trying something and not intending on keeping it, this generates files and burns level names unnecessarily, likely all stored in the same place as files you do use. It becomes a mess. If a user wants to save what they did, they will likely be hitting the save command or be prompted when they exit without saving. I dont expect this to be a popular opinion.

However, i think the real issue is when you change project setting Append $scenepath to... after creating levels and such, especially when you have an unsaved scene.

Unsaved scenes are stored in user's cache folder until you save. At that point it moves it to the real location. I seem to recall issues when $scenepath folders are involved. This might be due to OT automatically saving level files upon creation so internally it thinks its in the cache folder which would have been deleted after closing. Possible it was not moved to real location if it didnt think it needed to be saved. Also, not sure files are handled right if you changed use of $scenepath in an already established scene.

[janimatic]

@manongjohn @RodneyBaker and everyone,
Hello everyone and thanks for your replies,
When i first used Softimage::Toonz 4.6 in the 90's under Irix os (SGI), it was file based only, because it was a scan gouache ("inknpaint" from scanned drawing, we would even enter xsheet cells before starting auto document feeder scanning). I am still filming my paper drawings and like toonz traditional method (i write the timing on bar sheets/paper too).
But later versions and OT/Tahoma2D added paperless tools. I would love to avoid computer completly and the coding deamon distracting me from drawing, but hydrid paperless/paper is really interseting to reduce the price and production time of movies, plus for many other obvious reasons...
As i was trying to finish my oca importer (mainly to get krita brushes back and forth ), i realized that this new paperless
features raised the annoying subject of file vs memory management in a deep code base, based heavily on files.
I whish we could just add a few members/methods (for example of importer use case, m_originalPath variable would allow delayed file management of imported files), to create levels without defining file paths but only names and such variables,
and delay the moment of file path resolution with template string subsitution (we could even expand the $scenepath idea
to make a really easy to setup template system for big sutdios. I used to do it like softimage::xsi did, using variables to path
conversions for tokens like project, scene, version, frame, extension, etc... and we could easily expand this later to define custom
variables like shots etc... from the interface, but that's another topic...).
This would just happen on save. In my preferences, save all/save scene/save scene as/save scene version always save dirty levels and copy old levels to new path when needed and all use same methods (But as you know, only dirty cells are saved actually : that proves that toonz image sequences are never dealed as purely "in memory" for the moment...).

But i fear the octopuss of all the use cases, that would requiere a code cleanup and too much code rewrite.
I am curious about your visions !
In my personal tools projects, I use to define image sequences as vector (or deque) of pixels, add threaded load/save, etc... and have the same class used for players, recorders, texture/pixel/etc type conversions, image sequence parsing from filesystem, etc...
But i would really avoid to change toonz code base as much as possible (and finally restart drawing...), the Qt redesign is not old and, outside of the filepath mess, i like it, and even I saw some people started to replace pointers by shared_ptr for parts of code (project). Though in general, it would be nice to reuse the code more often (ex : many important features are coded directly in dialog classes, while they should at least be commands, or better, an easy to use api reused by menu calls, plugins, scripts etc...)
I believe this subject deserves sharing our ideas about it...
Thank you in advance!
best regards
Julien

[RodneyBaker]

Moving this to Opentoonz documents where it can be further discussed.