The catalog tree is a unit on its own, and should be tested separately.
This makes the testing files smaller and more focused, which can help
maintaining them.
This manages setting up asset library directories for testing, which is
useful for testing multiple asset library related compontents. So move
it to a common header. No reason to squeeze everything into one file
then.
No user visible changes expected.
`AssetIdentifier` holds information to uniquely identify and locate an
asset. More information:
https://wiki.blender.org/wiki/Source/Architecture/Asset_System/Back_End#Asset_Identifier
For the start this is tied quite a bit to file paths, so that external
assets are assumed to be in the file system.
This is needed to support an "All" asset library (see T102879), which
would contain assets from different locations. Currently the location of
an asset is queried via the file browser backend, which however requires
a common root location. It also moves us further away from the file
browser towards the asset system (see T87235) and allows us to remove
some hacks (see following commit).
No user visible changes expected.
If an asset library is located on disk, store the path to it in the
asset library data. This is called the "root path" now.
With this we can construct an asset identifier, which is introduced in
the following commit.
(Probably requires ASan for a reliable crash.)
Steps to reproduce were:
* Enter Geometry Nodes Workspace
* Press "New" button in the geometry nodes editor header
* Right-click the data-block selector -> "Mark as Asset"
* Change 3D View to Asset Browser
* Create a catalog
* Drag new Geometry Nodes asset into the catalog
* Save the file
* Press Shift+A in the geometry nodes editor
There was a general issue here with keeping catalog pointers around
during the add menu building. The way it does things, catalogs may be
reloaded in between.
Since the Current File asset library isn't loaded in a separate thread,
the use-after-free would always happen in between. For other libraries
it could still happen, but apparently didn't by chance.
A `using FooPtr = std::unique_ptr<Foo>` isn't that useful usually, just
saves a few character stokes. It obfuscates the underlying type, which
is usually relevant information. Plus, `Ptr` for a unique pointer is
misleading (should be `UPtr` or similar).
Move "using" declarations and member variables to the top of the class.
See https://wiki.blender.org/wiki/Style_Guide/C_Cpp#Class_Layout.
Changes access specifiers of some variables from public/protected to
private, there was no point in not having them private.
- Move main comment on class to header comment where it's more visible.
- Improve comment.
- Move stdlib includes first, like we do it usually
- Separate includes my code module
- Remove unnecessary forward declarations
Steps to reproduce were:
- Open an asset browser
- Open an asset library with assets in it
- Load a different file (e.g. File -> New -> General)
Didn't see a nice way to fix this with the current pre file load handler
callback we use for freeing asset libraries. Using this is cleaner, but
for now, the relationship between UI and asset system is too close
still, so better do explicit freeing at the right point in time.
- Move code to manage storage to own class in own file, separates
concerns and different levels of abstraction better.
- Store local ID assets separately in the storage class for more
efficient lookups (e.g. for ID remapping).
- Make API function names and comments more complete.
Using a vector to store assets means we have to lookup the position of
the asset to be able to remove/free it. Use a `blender::Set` instead for
(nearly?) constant time removal.
Adds a new `source/blender/asset_system` directory and moves asset
related files from BKE to it. More asset related code can follow
(e.g. asset indexing, ED_assetlist stuff) but needs further work to
untangle it. I also kept `BKE_asset.h` and `asset.cc` as is, since they
deal with asset DNA data mostly, thus make sense in BKE.
Motivation:
- Makes the asset system design more present (term wasn't even used in
code before).
- An `asset_system` directory is quite descriptive (trivial to identify
core asset system features) and makes it easy to find asset code.
- Asset system is mostly runtime data, with little relation to other
`Main`/BKE/DNA types.
- There's a lot of stuff in BKE already. It shouldn't be just a dump for
all stuff that seems core enough.
- Being its own directly helps us be more mindful about encapsulating
the module well, and avoiding dependencies on other modules.
- We can be more free with splitting files here than in BKE.
- In future there might be an asset system BPY module, which would then
map quite nicely to the `asset_system` directory.
Checked with some other core devs, consensus seems that this makes
sense.
