Previously all blend files included the path they were saved,
causing files distributed publicly to include users local paths.
This also included developers home directories for startup & userprefs
defaults & app-templates bundled with Blender.
Now recovery information is only written for auto-save & quit.blend
since this is the only time they're intended to be used.
Currently file loading performs almost all reloading logic
even in the case loading the file fails, causing the file to be in
a state that isn't well defined: undo is cleared, timers are canceled &
scripts are re-registered.
Move `eUndoStepDir` to `BKE_undo_system.h` and use its values
everywhere.
Note that this also introduce the `STEP_INVALID` value in that enum.
Finally, kept the matching struct members in some lower-level readfile
code as an `int` to avoid having to include `BKE_undo_system.h` in a lot
of unrelated files.
This removes G_FILE_HISTORY, G_FILE_SAVE_COPY & G_FILE_USERPREFS.
Using file-flags made logic harder to follow since it's not so clear
which flags are expected to be in G.fileflags & which are meant to be
set and passed as arguments, these are shared between read & write
functions too.
Add BlendFileWriteParams so options which don't need to be stored
aren't mixed up with flags that are stored for reuse.
When "Relative Remap" option was added, the intention was only to remap
paths that were already relative. However it remapped all paths.
This was reported as T62612 and fixed recently,
however some Python script authors depended on the old behavior.
For users, it's reasonable to use the existing operators to make paths
absolute/relative. For scripts however it's useful to be able to write
out individual data-blocks with the ability to make all paths relative.
Now `bpy.data.libraries.write()` takes a path_remap argument which can
be `NONE/RELATIVE/RELATIVE_ALL/ABSOLUTE` allowing the script author to
choose how paths are handled when writing out data-blocks.
Addresses T77768.
Clear is_identical_future before adding a next undo step, to avoid wrong
values for cases where we undo and then add a step with different changes
than what was previously the next step.
Ref D7274
The feature is hidden behind an experimental option, you'll have to
enable it in the preferences to try it.
This feature is not yet considered fully stable, crashes may happen, as
well as .blend file corruptions (very unlikely, but still possible).
In a nutshell, the ideas behind this code are to:
* Detect unchanged IDs across an undo step.
* Reuse as much as possible existing IDs memory, even when its content
did change.
* Re-use existing depsgraphs instead of building new ones from scratch.
* Store accumulated recalc flags, to avoid needless re-compute of things
that did not change, when the ID itself is detected as modified.
See T60695 and D6580 for more technical details.
BF-admins agree to remove header information that isn't useful,
to reduce noise.
- BEGIN/END license blocks
Developers should add non license comments as separate comment blocks.
No need for separator text.
- Contributors
This is often invalid, outdated or misleading
especially when splitting files.
It's more useful to git-blame to find out who has developed the code.
See P901 for script to perform these edits.
That kind of implicit includes should really only be done when totally,
absolutely necessary, and ideally only with rather simple 'second-level'
headers.
Otherwise not being explicit with includes always end up biting in
unexpected ways...
- Undo that changes modes currently asserts,
since undo is now screen data.
Most likely we will change how object mode and workspaces work
since it's not practical/maintainable at the moment.
- Removed view_layer from particle settings
(wasn't needed and complicated undo).
- Use a single undo history for all operations.
- UndoType's are registered and poll the context to check if they
should be used when performing an undo push.
- Mode switching is used to ensure the state is correct before
undo data is restored.
- Some undo types accumulate changes (image & text editing)
others store the state multiple times (with de-duplication).
This is supported by checking UndoStack.mode `ACCUMULATE` / `STORE`.
- Each undo step stores ID datablocks they use with utilities to help
manage restoring correct ID's.
Needed since global undo is now mixed with other modes undo.
- Currently performs each undo step when going up/down history
Previously this wasn't done, making history fail in some cases.
This can be optimized to skip some combinations of undo steps.
grease-pencil is an exception which has not been updated
since it integrates undo into the draw-session.
See D3113
- Get memory usage from MemFile instead of MEM API
avoids possible invalid when threads alloc memory.
- Use size_t instead of uint and uintptr_t to store size.
- Rename UndoElem.str -> filename
- Rename MemFileChunk.ident -> is_identical
Internal change needed for template support.
Loading the user preferences first so it's possible
for preferences to control startup behavior.
In general it's useful to load preferences before data-files,
so we know security settings for eg.
This option makes an operator to not push a task to the undo stack if the previous stored elemen is the same operator or part of the same undo group.
The main usage is for animation, so you can change frames to inspect the
poses, and revert the previous pose without having to roll back tons of
"change frame" operator, or even see the undo stack full.
This complements rB13ee9b8e
Design with help by Sergey Sharybin.
Reviewers: sergey, mont29
Reviewed By: mont29, sergey
Subscribers: pyc0d3r, hjalti, Severin, lowercase, brecht, monio, aligorith, hadrien, jbakker
Differential Revision: https://developer.blender.org/D2330
