| Age | Commit message (Collapse) | Author |
|---|
|
While relatively minor issue, it could become fairly annoying in a big
project, since once an ID is tagged as directly linked it tend to remain
as such.
Now also force indirect tagging when loading new IDs as part of a lib
relocation process, since the ones actually directly linked will be
tagged as such later on.
|
|
Use a shorter/simpler license convention, stops the header taking so
much space.
Follow the SPDX license specification: https://spdx.org/licenses
- C/C++/objc/objc++
- Python
- Shell Scripts
- CMake, GNUmakefile
While most of the source tree has been included
- `./extern/` was left out.
- `./intern/cycles` & `./intern/atomic` are also excluded because they
use different header conventions.
doc/license/SPDX-license-identifiers.txt has been added to list SPDX all
used identifiers.
See P2788 for the script that automated these edits.
Reviewed By: brecht, mont29, sergey
Ref D14069
|
|
In almost all cases there is no difference between `G.relbase_valid`
and checking `G.main->filepath` isn't an empty string.
In many places a non-empty string is already being used instead of
`G.relbase_valid`.
The only situation where this was needed was when saving from
`wm_file_write` where they temporarily became out of sync.
This has been replaced by adding a new member to `BlendFileWriteParams`
to account for saving an unsaved file for the first time.
Reviewed By: brecht
Ref D13564
|
|
Ref T92709
|
|
This enables calling code to deal with the blendfile handle themselves,
BKE_blendfile_link then just borrows, uses this handle and does not
release it.
Needed e.g. for python's libcontext system to use new
BKE_blendfile_link_append code.
Part of T91414: Unify link/append between WM operators and BPY context
manager API, and cleanup usages of `BKE_library_make_local`.
|
|
This allows to reduce signature of several functions, and make it eaiser
to integrate more higher-level usages later on.
This should be a non-behavioral-change commit.
Part of T91414: Unify link/append between WM operators and BPY context
manager API, and cleanup usages of `BKE_library_make_local`.
|
|
`BKE_blendflie_link_append` module.
This will allow to expose all those advanced features of the WM
operators to other parts of the code, like the python library context
manager, copy/paste code, etc.
This is expected to be a strictly no-behavioral-change commit.
Part of T91414: Unify link/append between WM operators and BPY context
manager API, and cleanup usages of `BKE_library_make_local`.
Maniphest Tasks: T91414
Differential Revision: https://developer.blender.org/D13222
|
|
|
|
|
|
* Name generated 'append' collection, instead of getting a generic
meaningless name.
* Do not check if a collections's objects are already instantiated, when
we already know that we want to instantiate that collection.
|
|
rB43bc494892c3 switched `BKE_libblock_relink_to_newid` to use new ID
remapping and libquery code.
However, that new code does protect by default against remapping an
objects's data pointer when that object is in Edit mode, since this is
not a behavior that generic BKE code can handle (due to required editing
data for most obdata types when in edit mode).
So specific code that does create new IDs and need remapping in Edit
mode has to pass specific exception flags to remaping code.
This commit adds those remapping flags to `BKE_libblock_relink_to_newid`
and add said exception flag to the remapping call from
`ED_object_add_duplicate` when the object is in edit mode.
|
|
Move all usages to new `BKE_libblock_relink_to_newid_new`, and rename
that one to `BKE_libblock_relink_to_newid`.
Fix T91413.
|
|
Shapekeys, always shapekeys... Since we cannot deal with them as regular
IDs, we need to handle potential recursion cases ourselves here. sigh.
|
|
When appending an asset from the asset browser, its asset data needs to
be cleared.
However, linking an asset (or regular append from the file browser)
should not clear such data. In linking case, it would be there again
after a blend file reload anyway.
So this commit introduces a new `BLO_LIBLINK_APPEND_ASSET_DATA_CLEAR`
option.
NOTE: in case the appended ID needs to be copied from its linked data
(instead of making the later directly local), asset data is lost anyway
since it is never copied with the ID currently.
Ref. {T91749} and D11768.
|
|
De-duplicates wm_append_loose_data_instantiate_object_base_instance_init
and object_base_instance_init.
Add BLO_object_instantiate_object_base_instance_init which also adds to
a collection since all callers did this.
|
|
directly.
Collections directly selected by the user should always be
instantiated.
Regression from recent append code refactor.
|
|
'localize all' off.
In 2.93 and before, when appending wityh 'localize all' off, all linked
IDs (including indirectly linked ones) from initial library would be
made local.
In 3.0, after refactor from rB3be5ce4aad5e, only directly linked IDs
(i.e. user-selected IDs) would be made local.
This change was not intentional (result of confusing code and naming in
previous implementation), and old behavior is used in some workflows to
control which data is kept linked and which data is made local.
This commit revert to 2.93 behavior.
NOTE: there is still an (extreme) corner case where behavior is
different between 2.93 and 3.0:
If you append (at the same time) object A from LibA.blend, and object B
from LibB.blend, and object B uses somehow a material from LibA.blend:
* In 2.93, that material would have been made local (because it belonged
to one of the 'initial' libraries, even though not the initial lib of
object B).
* In 3.0, this material will remain linked, since from object B
persective it comes from a different library.
|
|
|
|
Keep track of the source library allowing other parts of the code to
to make better decisions. This is needed to localize external files.
In this case the file paths are updated when `making local`.
But we should decide based on the source library if we want to
copy the file relative to the new blend file. See D12423.
Reviewed By: mont29, Severin
Differential Revision: https://developer.blender.org/D12765
|
|
Liboverride references need a special handling during append, since
those pointers should never be made local, nor reampped to newly
localized data. And liboverride references should never be directly made
local either, to ensure their liboverride usages remain pointing to
linked data and not local one.
Issue was reported by the studio, and also probably as part of T91892.
|
|
This was simply never handled apparently.
Also fixes a regression from recent append refactor that prevented RB
objects to to properly handled too (since we instantiate loose objects
in append step now, we need to handle RigidBody ones after that
instantiation stage, otherwise nothing will happen since loose objects
won't be in any scene).
|
|
Recent append refactor 'broke' this, we need special recursive care and
handling of those nasty shpae keys... again.
|
|
* ID pointer returned by `wm_file_link_append_datablock_ex` was
improperly extracted from `WMLinkAppendDataItem` before append step.
* Code deleting linked IDs when their local matching version was re-used
did not properly clear `LIB_TAG_DOIT` beforehand.
|
|
There is no reason to lock behavior into a specific configuration in
those calls, make them properly configurable like the rest of the
link/append code.
This also enable users of those functions to activate 'ID reuse'
behavior.
|
|
Option is now available to append operator, alsthough hidden and
disabled by default.
|
|
When we re-use a local ID, we need to delete the matching linked data.
|
|
|
|
in asset context, when user drag & drop a material several time, they
would still expect to re-use existing one instead of getting new copies
of it, even if this material is directly appended (and not an indirect
dependency of an object e.g.).
|
|
Flags controlling link/append code are split between two enums, one in
`DNA_space_types.h` and one in `BLO_readfile.h`.
This commit:
- Moves flags exclusively used in WM and BLO code to `eBLOLibLinkFlags`
in `BLO_readfile.h`. Flags in `eFileSel_Params_Flag` from
`DNA_space_types.h` are now only the ones effectively used by the
file browser editor code too.
- Fixes some internal utils in `readfile.c` still taking `short` flag
parameter instead of proper `int` one.
NOTE: there are a few other flags that could probably be moved to
`eBLOLibLinkFlags` (at the very least `FILE_LINK`, probably also
`FILE_AUTOSELECT` and `FILE_ACTIVE_COLLECTION`), since those are not
effectively used by the file browser, and control linking/appending
behavior, not filebrowser behavior.
However for now think it's safer to not touch that.
|
|
|
|
This commit adds to ID struct a new optional 'weak reference' to a
linked ID (in the form of a blend file library path and full ID name).
This can then be used on next append to try to find a matching local ID
instead of re-making the linked data local again.
Ref. T90545
NOTE: ID re-use will be disabled for regular append for the time being
(3.0 release), and only used for assets. Therefore, this commit should
not change anything user-wise.
Differential Revision: https://developer.blender.org/D12545
|
|
This code path is not yet used so no harm, but that was a fairly nasty
potential crash-generator.
|
|
|
|
Add needed extra flag and utils to IDType to mark and check an ID type
as only appendable.
Note that this is only a loose user-level enforcement currently, in any
case you need to be able to link an ID to append it currently, so for
low-level code this does not really matter.
Currently only WorkSpace and Screen ID types are marked with the new
`IDTYPE_FLAGS_ONLY_APPEND` flag.
|
|
Mixing testing and actual action in a single function is just not a good
way to do things, and the 'testing' feature is not used anywhere
anymore, time to get rid of it.
|
|
Scene and related pointer parameter can be NULL in link/append code, in
which case there is no instantiation of new objects/collections/obdata.
Link code in blendloader was already checking that, new instantiation
code in WM area from yesterday did not.
Issue introduced by rB3be5ce4aad5e.
|
|
|
|
|
|
This commit fully refactors the way linked IDs are made local when
appended.
Previously, `BKE_library_make_local` was (ab)used for this task, but it
was missing some contextual data and doing complex processing to try to
work around this, with limited sucess. Further more, it was nearly
impossibe to extend (e.g. to get new append behaviors necessary for the
asset project).
The new code is a dedicated append step in WM linking process.
NOTE: BPY API (`libray.load()` context manager) uses its own code here,
which still relies on `BKE_library_make_local` for appending.
Unfortunately, merging those two different code paths is not trivial so
for now this API will remain unchanged.
Fix T55629: Append already linked Data is impossible.
|
|
|
|
There was already some code for that, but it was broken, and proper
resync was completely missing.
There might still be more resync needed in library linking operators
though.
|
|
|
|
More stupid mistake in recent enhanced reports for file load code,
rB82c17082ba0e left some read-after-free situations.
|
|
This reverts commit rB3a48147b8ab92, and fixes the issues with linking
etc.
Change compared to previous buggy commit (rBf8d219dfd4c31) is that
new `BlendFileReadReports` reports are now passed to the lowest level
function generating the `FileData` (`filedata_new()`), which ensures
(and asserts) that all code using it does have a valid non-NULL pointer
to a `BlendFileReadReport` data.
Sorry for the noise, it's always when you think a change is trivial and
do not test it well enough that you end up doing those kind of
mistakes...
|
|
This patch fixes many minor spelling mistakes, all in comments or
console output. Mostly contractions like can't, won't, don't, its/it's,
etc.
Differential Revision: https://developer.blender.org/D11663
Reviewed by Harley Acheson
|
|
Note: Linking in this case as in link vs. append. Easily confused with linking
a data-block to multiple usages (e.g. single material used by multiple
objects).
Adds a drop-down to the Asset Browser header to choose between Link and Append.
This is probably gonna be a temporary place, T54642 shows where this could be
placed eventually.
Linking support is crucial for usage of the asset browser in production
environments. It just wasn't enabled yet because a) the asset project currently
focuses on single user, not production assets, and b) because there were many
unkowns still for the workflow that have big impact on production use as well.
With the recently held asset workshop I'm more confident with enabling linking,
as design ideas relevant to production use were confirmed.
Differential Revision: https://developer.blender.org/D11536
Reviewed by: Bastien Montagne
|
|
|
|
This allows adding ID tags when linking/loading data.
This is needed to implement loading non 'G.main' ID data-blocks,
see D10612.
|
|
The `MAX_LIBARRAY` define was an annoying doublon to the `INDEX_ID_MAX` enum value
now defined in `DNA_ID.h`, and it is no more useful.
And comments were somewhat outdated. Also added an explanation about
chosen order for the `INDEX_ID_<IDTYPE>` order.
|
|
Changes include using proper and consistent grammar, simplifying
phrasing, using correct terminology, and not including python API
identifiers in tooltips.
Differential Revision: https://developer.blender.org/D9924
|
