2023-08-16 00:20:26 +10:00
|
|
|
/* SPDX-FileCopyrightText: 2023 Blender Authors
|
2023-05-31 16:19:06 +02:00
|
|
|
*
|
|
|
|
|
* SPDX-License-Identifier: GPL-2.0-or-later */
|
2020-12-11 18:15:25 +01:00
|
|
|
|
|
|
|
|
/** \file
|
|
|
|
|
* \ingroup bke
|
|
|
|
|
*/
|
|
|
|
|
|
2021-02-15 15:30:17 +01:00
|
|
|
#include <cstring>
|
2020-12-11 18:15:25 +01:00
|
|
|
|
2021-02-06 02:18:38 +01:00
|
|
|
#include "DNA_ID.h"
|
|
|
|
|
#include "DNA_defaults.h"
|
|
|
|
|
|
2020-12-11 18:15:25 +01:00
|
|
|
#include "BLI_listbase.h"
|
|
|
|
|
#include "BLI_string.h"
|
Assets: add Asset Catalog system
Catalogs work like directories on disk (without hard-/symlinks), in that
an asset is only contained in one catalog.
See T90066 for design considerations.
#### Known Limitations
Only a single catalog definition file (CDF), is supported, at
`${ASSET_LIBRARY_ROOT}/blender_assets.cats.txt`. In the future this is
to be expanded to support arbitrary CDFs (like one per blend file, one
per subdirectory, etc.).
The current implementation is based on the asset browser, which in
practice means that the asset browser owns the `AssetCatalogService`
instance for the selected asset library. In the future these instances
will be accessible via a less UI-bound asset system.
The UI is still very rudimentary, only showing the catalog ID for the
currently selected asset. Most notably, the loaded catalogs are not
shown yet. The UI is being implemented and will be merged soon.
#### Catalog Identifiers
Catalogs are internally identified by UUID. In older designs this was a
human-readable name, which has the problem that it has to be kept in
sync with its semantics (so when renaming a catalog from X to Y, the
UUID can be kept the same).
Since UUIDs don't communicate any human-readable information, the
mapping from catalog UUID to its path (stored in the Catalog Definition
File, CDF) is critical for understanding which asset is stored in which
human-readable catalog. To make this less critical, and to allow manual
data reconstruction after a CDF is lost/corrupted, each catalog also has
a "simple name" that's stored along with the UUID. This is also stored
on each asset, next to the catalog UUID.
#### Writing to Disk
Before saving asset catalogs to disk, the to-be-overwritten file gets
inspected. Any new catalogs that are found thre are loaded to memory
before writing the catalogs back to disk:
- Changed catalog path: in-memory data wins
- Catalogs deleted on disk: they are recreated based on in-memory data
- Catalogs deleted in memory: deleted on disk as well
- New catalogs on disk: are loaded and thus survive the overwriting
#### Tree Design
This implements the initial tree structure to load catalogs into. See
T90608, and the basic design in T90066.
Reviewed By: Severin
Maniphest Tasks: T91552
Differential Revision: https://developer.blender.org/D12589
2021-09-23 14:56:45 +02:00
|
|
|
#include "BLI_string_ref.hh"
|
2023-09-01 11:36:11 +10:00
|
|
|
#include "BLI_string_utf8.h"
|
2023-10-18 17:15:30 +02:00
|
|
|
#include "BLI_string_utils.hh"
|
Assets: add Asset Catalog system
Catalogs work like directories on disk (without hard-/symlinks), in that
an asset is only contained in one catalog.
See T90066 for design considerations.
#### Known Limitations
Only a single catalog definition file (CDF), is supported, at
`${ASSET_LIBRARY_ROOT}/blender_assets.cats.txt`. In the future this is
to be expanded to support arbitrary CDFs (like one per blend file, one
per subdirectory, etc.).
The current implementation is based on the asset browser, which in
practice means that the asset browser owns the `AssetCatalogService`
instance for the selected asset library. In the future these instances
will be accessible via a less UI-bound asset system.
The UI is still very rudimentary, only showing the catalog ID for the
currently selected asset. Most notably, the loaded catalogs are not
shown yet. The UI is being implemented and will be merged soon.
#### Catalog Identifiers
Catalogs are internally identified by UUID. In older designs this was a
human-readable name, which has the problem that it has to be kept in
sync with its semantics (so when renaming a catalog from X to Y, the
UUID can be kept the same).
Since UUIDs don't communicate any human-readable information, the
mapping from catalog UUID to its path (stored in the Catalog Definition
File, CDF) is critical for understanding which asset is stored in which
human-readable catalog. To make this less critical, and to allow manual
data reconstruction after a CDF is lost/corrupted, each catalog also has
a "simple name" that's stored along with the UUID. This is also stored
on each asset, next to the catalog UUID.
#### Writing to Disk
Before saving asset catalogs to disk, the to-be-overwritten file gets
inspected. Any new catalogs that are found thre are loaded to memory
before writing the catalogs back to disk:
- Changed catalog path: in-memory data wins
- Catalogs deleted on disk: they are recreated based on in-memory data
- Catalogs deleted in memory: deleted on disk as well
- New catalogs on disk: are loaded and thus survive the overwriting
#### Tree Design
This implements the initial tree structure to load catalogs into. See
T90608, and the basic design in T90066.
Reviewed By: Severin
Maniphest Tasks: T91552
Differential Revision: https://developer.blender.org/D12589
2021-09-23 14:56:45 +02:00
|
|
|
#include "BLI_uuid.h"
|
2020-12-11 18:15:25 +01:00
|
|
|
|
|
|
|
|
#include "BKE_asset.h"
|
|
|
|
|
#include "BKE_idprop.h"
|
2023-09-04 18:02:16 +02:00
|
|
|
#include "BKE_preview_image.hh"
|
2020-12-11 18:15:25 +01:00
|
|
|
|
2023-08-28 15:01:05 +02:00
|
|
|
#include "BLO_read_write.hh"
|
2020-12-11 18:15:25 +01:00
|
|
|
|
|
|
|
|
#include "MEM_guardedalloc.h"
|
|
|
|
|
|
Assets: add Asset Catalog system
Catalogs work like directories on disk (without hard-/symlinks), in that
an asset is only contained in one catalog.
See T90066 for design considerations.
#### Known Limitations
Only a single catalog definition file (CDF), is supported, at
`${ASSET_LIBRARY_ROOT}/blender_assets.cats.txt`. In the future this is
to be expanded to support arbitrary CDFs (like one per blend file, one
per subdirectory, etc.).
The current implementation is based on the asset browser, which in
practice means that the asset browser owns the `AssetCatalogService`
instance for the selected asset library. In the future these instances
will be accessible via a less UI-bound asset system.
The UI is still very rudimentary, only showing the catalog ID for the
currently selected asset. Most notably, the loaded catalogs are not
shown yet. The UI is being implemented and will be merged soon.
#### Catalog Identifiers
Catalogs are internally identified by UUID. In older designs this was a
human-readable name, which has the problem that it has to be kept in
sync with its semantics (so when renaming a catalog from X to Y, the
UUID can be kept the same).
Since UUIDs don't communicate any human-readable information, the
mapping from catalog UUID to its path (stored in the Catalog Definition
File, CDF) is critical for understanding which asset is stored in which
human-readable catalog. To make this less critical, and to allow manual
data reconstruction after a CDF is lost/corrupted, each catalog also has
a "simple name" that's stored along with the UUID. This is also stored
on each asset, next to the catalog UUID.
#### Writing to Disk
Before saving asset catalogs to disk, the to-be-overwritten file gets
inspected. Any new catalogs that are found thre are loaded to memory
before writing the catalogs back to disk:
- Changed catalog path: in-memory data wins
- Catalogs deleted on disk: they are recreated based on in-memory data
- Catalogs deleted in memory: deleted on disk as well
- New catalogs on disk: are loaded and thus survive the overwriting
#### Tree Design
This implements the initial tree structure to load catalogs into. See
T90608, and the basic design in T90066.
Reviewed By: Severin
Maniphest Tasks: T91552
Differential Revision: https://developer.blender.org/D12589
2021-09-23 14:56:45 +02:00
|
|
|
using namespace blender;
|
|
|
|
|
|
2021-12-08 00:31:20 -05:00
|
|
|
AssetMetaData *BKE_asset_metadata_create()
|
2020-12-11 18:15:25 +01:00
|
|
|
{
|
Asset System: New core type to represent assets (`AssetRepresenation`)
Introduces a new `AssetRepresentation` type, as a runtime only container
to hold asset information. It is supposed to become _the_ main way to
represent and refer to assets in the asset system, see T87235. It can
store things like the asset name, asset traits, preview and other asset
metadata.
Technical documentation:
https://wiki.blender.org/wiki/Source/Architecture/Asset_System/Back_End#Asset_Representation.
By introducing a proper asset representation type, we do an important
step away from the previous, non-optimal representation of assets as
files in the file browser backend, and towards the asset system as
backend. It should replace the temporary & hacky `AssetHandle` design in
the near future. Note that the loading of asset data still happens
through the file browser backend, check the linked to Wiki page for more
information on that.
As a side-effect, asset metadata isn't stored in file browser file
entries when browsing with link/append anymore. Don't think this was
ever used, but scripts may have accessed this. Can be brought back if
there's a need for it.
2022-11-09 18:34:31 +01:00
|
|
|
const AssetMetaData *default_metadata = DNA_struct_default_get(AssetMetaData);
|
|
|
|
|
return MEM_new<AssetMetaData>(__func__, *default_metadata);
|
2020-12-11 18:15:25 +01:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
void BKE_asset_metadata_free(AssetMetaData **asset_data)
|
|
|
|
|
{
|
2022-12-02 19:07:42 +01:00
|
|
|
MEM_delete(*asset_data);
|
|
|
|
|
*asset_data = nullptr;
|
Asset System: New core type to represent assets (`AssetRepresenation`)
Introduces a new `AssetRepresentation` type, as a runtime only container
to hold asset information. It is supposed to become _the_ main way to
represent and refer to assets in the asset system, see T87235. It can
store things like the asset name, asset traits, preview and other asset
metadata.
Technical documentation:
https://wiki.blender.org/wiki/Source/Architecture/Asset_System/Back_End#Asset_Representation.
By introducing a proper asset representation type, we do an important
step away from the previous, non-optimal representation of assets as
files in the file browser backend, and towards the asset system as
backend. It should replace the temporary & hacky `AssetHandle` design in
the near future. Note that the loading of asset data still happens
through the file browser backend, check the linked to Wiki page for more
information on that.
As a side-effect, asset metadata isn't stored in file browser file
entries when browsing with link/append anymore. Don't think this was
ever used, but scripts may have accessed this. Can be brought back if
there's a need for it.
2022-11-09 18:34:31 +01:00
|
|
|
}
|
|
|
|
|
|
Assets: allow copying asset data from one ID to another
Asset data can now be copied in Python via assignment to
`id.asset_data`, so for example `dest.asset_data = source.asset_data`.
This copies the description, license, author, etc. fields, as well as
the tags and the asset catalog assignment.
This is intended to be used in the pose library, when updating a pose by
simply creating a new asset and having that replace the old one.
This is intentionally taking a copy, even though the above use case
could have sufficed with a higher-level 'move' function. By exposing
this as a copy, it can be used in a wider range of situations, from
whatever Python code wants to use it. This could include copying the
asset data from the active asset to all the other selected ones.
Any pre-existing asset data is freed before the copy is assigned. The
target ID MUST be marked as asset already for the assignment to work.
Assigning `None` to clear the asset status is not allowed. Instead
`.asset_mark()` resp. `.asset_clear()` should be used. This limitation
is in place to simplify the API, and to ensure that there is only one
way in which assets are marked/cleared, making it easier to change the
internals of the asset system without API changes.
Example code:
```python
src = bpy.data.objects['Suzanne']
dst = bpy.data.objects['Cube']
dst.asset_mark()
dst.asset_data = src.asset_data
```
Pull Request: https://projects.blender.org/blender/blender/pulls/108547
2023-06-02 16:07:41 +02:00
|
|
|
AssetMetaData *BKE_asset_metadata_copy(const AssetMetaData *source)
|
|
|
|
|
{
|
|
|
|
|
AssetMetaData *copy = BKE_asset_metadata_create();
|
|
|
|
|
|
|
|
|
|
copy->local_type_info = source->local_type_info;
|
|
|
|
|
|
|
|
|
|
if (source->properties) {
|
|
|
|
|
copy->properties = IDP_CopyProperty(source->properties);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
BKE_asset_metadata_catalog_id_set(copy, source->catalog_id, source->catalog_simple_name);
|
|
|
|
|
|
|
|
|
|
if (source->author) {
|
|
|
|
|
copy->author = BLI_strdup(source->author);
|
|
|
|
|
}
|
|
|
|
|
if (source->description) {
|
|
|
|
|
copy->description = BLI_strdup(source->description);
|
|
|
|
|
}
|
|
|
|
|
if (source->copyright) {
|
|
|
|
|
copy->copyright = BLI_strdup(source->copyright);
|
|
|
|
|
}
|
|
|
|
|
if (source->license) {
|
|
|
|
|
copy->license = BLI_strdup(source->license);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
BLI_duplicatelist(©->tags, &source->tags);
|
|
|
|
|
copy->active_tag = source->active_tag;
|
|
|
|
|
copy->tot_tags = source->tot_tags;
|
|
|
|
|
|
|
|
|
|
return copy;
|
|
|
|
|
}
|
|
|
|
|
|
Asset System: New core type to represent assets (`AssetRepresenation`)
Introduces a new `AssetRepresentation` type, as a runtime only container
to hold asset information. It is supposed to become _the_ main way to
represent and refer to assets in the asset system, see T87235. It can
store things like the asset name, asset traits, preview and other asset
metadata.
Technical documentation:
https://wiki.blender.org/wiki/Source/Architecture/Asset_System/Back_End#Asset_Representation.
By introducing a proper asset representation type, we do an important
step away from the previous, non-optimal representation of assets as
files in the file browser backend, and towards the asset system as
backend. It should replace the temporary & hacky `AssetHandle` design in
the near future. Note that the loading of asset data still happens
through the file browser backend, check the linked to Wiki page for more
information on that.
As a side-effect, asset metadata isn't stored in file browser file
entries when browsing with link/append anymore. Don't think this was
ever used, but scripts may have accessed this. Can be brought back if
there's a need for it.
2022-11-09 18:34:31 +01:00
|
|
|
AssetMetaData::~AssetMetaData()
|
|
|
|
|
{
|
|
|
|
|
if (properties) {
|
|
|
|
|
IDP_FreeProperty(properties);
|
2020-12-11 18:15:25 +01:00
|
|
|
}
|
Asset System: New core type to represent assets (`AssetRepresenation`)
Introduces a new `AssetRepresentation` type, as a runtime only container
to hold asset information. It is supposed to become _the_ main way to
represent and refer to assets in the asset system, see T87235. It can
store things like the asset name, asset traits, preview and other asset
metadata.
Technical documentation:
https://wiki.blender.org/wiki/Source/Architecture/Asset_System/Back_End#Asset_Representation.
By introducing a proper asset representation type, we do an important
step away from the previous, non-optimal representation of assets as
files in the file browser backend, and towards the asset system as
backend. It should replace the temporary & hacky `AssetHandle` design in
the near future. Note that the loading of asset data still happens
through the file browser backend, check the linked to Wiki page for more
information on that.
As a side-effect, asset metadata isn't stored in file browser file
entries when browsing with link/append anymore. Don't think this was
ever used, but scripts may have accessed this. Can be brought back if
there's a need for it.
2022-11-09 18:34:31 +01:00
|
|
|
MEM_SAFE_FREE(author);
|
|
|
|
|
MEM_SAFE_FREE(description);
|
2023-03-07 18:22:43 +01:00
|
|
|
MEM_SAFE_FREE(copyright);
|
|
|
|
|
MEM_SAFE_FREE(license);
|
Asset System: New core type to represent assets (`AssetRepresenation`)
Introduces a new `AssetRepresentation` type, as a runtime only container
to hold asset information. It is supposed to become _the_ main way to
represent and refer to assets in the asset system, see T87235. It can
store things like the asset name, asset traits, preview and other asset
metadata.
Technical documentation:
https://wiki.blender.org/wiki/Source/Architecture/Asset_System/Back_End#Asset_Representation.
By introducing a proper asset representation type, we do an important
step away from the previous, non-optimal representation of assets as
files in the file browser backend, and towards the asset system as
backend. It should replace the temporary & hacky `AssetHandle` design in
the near future. Note that the loading of asset data still happens
through the file browser backend, check the linked to Wiki page for more
information on that.
As a side-effect, asset metadata isn't stored in file browser file
entries when browsing with link/append anymore. Don't think this was
ever used, but scripts may have accessed this. Can be brought back if
there's a need for it.
2022-11-09 18:34:31 +01:00
|
|
|
BLI_freelistN(&tags);
|
|
|
|
|
}
|
2020-12-11 18:15:25 +01:00
|
|
|
|
|
|
|
|
static AssetTag *asset_metadata_tag_add(AssetMetaData *asset_data, const char *const name)
|
|
|
|
|
{
|
2021-02-06 02:18:38 +01:00
|
|
|
AssetTag *tag = (AssetTag *)MEM_callocN(sizeof(*tag), __func__);
|
2023-09-01 11:36:11 +10:00
|
|
|
STRNCPY_UTF8(tag->name, name);
|
2020-12-11 18:15:25 +01:00
|
|
|
|
|
|
|
|
BLI_addtail(&asset_data->tags, tag);
|
|
|
|
|
asset_data->tot_tags++;
|
|
|
|
|
/* Invariant! */
|
|
|
|
|
BLI_assert(BLI_listbase_count(&asset_data->tags) == asset_data->tot_tags);
|
|
|
|
|
|
|
|
|
|
return tag;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
AssetTag *BKE_asset_metadata_tag_add(AssetMetaData *asset_data, const char *name)
|
|
|
|
|
{
|
|
|
|
|
AssetTag *tag = asset_metadata_tag_add(asset_data, name);
|
|
|
|
|
BLI_uniquename(&asset_data->tags, tag, name, '.', offsetof(AssetTag, name), sizeof(tag->name));
|
|
|
|
|
return tag;
|
|
|
|
|
}
|
|
|
|
|
|
2023-06-03 08:36:28 +10:00
|
|
|
AssetTagEnsureResult BKE_asset_metadata_tag_ensure(AssetMetaData *asset_data, const char *name)
|
2020-12-11 18:15:25 +01:00
|
|
|
{
|
2023-06-03 08:36:28 +10:00
|
|
|
AssetTagEnsureResult result = {nullptr};
|
2020-12-11 18:15:25 +01:00
|
|
|
if (!name[0]) {
|
|
|
|
|
return result;
|
|
|
|
|
}
|
|
|
|
|
|
2021-02-06 02:18:38 +01:00
|
|
|
AssetTag *tag = (AssetTag *)BLI_findstring(&asset_data->tags, name, offsetof(AssetTag, name));
|
2020-12-11 18:15:25 +01:00
|
|
|
|
|
|
|
|
if (tag) {
|
|
|
|
|
result.tag = tag;
|
|
|
|
|
result.is_new = false;
|
|
|
|
|
return result;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
tag = asset_metadata_tag_add(asset_data, name);
|
|
|
|
|
|
|
|
|
|
result.tag = tag;
|
|
|
|
|
result.is_new = true;
|
|
|
|
|
return result;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
void BKE_asset_metadata_tag_remove(AssetMetaData *asset_data, AssetTag *tag)
|
|
|
|
|
{
|
|
|
|
|
BLI_assert(BLI_findindex(&asset_data->tags, tag) >= 0);
|
|
|
|
|
BLI_freelinkN(&asset_data->tags, tag);
|
|
|
|
|
asset_data->tot_tags--;
|
|
|
|
|
/* Invariant! */
|
|
|
|
|
BLI_assert(BLI_listbase_count(&asset_data->tags) == asset_data->tot_tags);
|
|
|
|
|
}
|
|
|
|
|
|
2021-07-08 22:16:50 +02:00
|
|
|
void BKE_asset_library_reference_init_default(AssetLibraryReference *library_ref)
|
|
|
|
|
{
|
|
|
|
|
memcpy(library_ref, DNA_struct_default_get(AssetLibraryReference), sizeof(*library_ref));
|
|
|
|
|
}
|
|
|
|
|
|
2023-06-03 08:36:28 +10:00
|
|
|
void BKE_asset_metadata_catalog_id_clear(AssetMetaData *asset_data)
|
Assets: add Asset Catalog system
Catalogs work like directories on disk (without hard-/symlinks), in that
an asset is only contained in one catalog.
See T90066 for design considerations.
#### Known Limitations
Only a single catalog definition file (CDF), is supported, at
`${ASSET_LIBRARY_ROOT}/blender_assets.cats.txt`. In the future this is
to be expanded to support arbitrary CDFs (like one per blend file, one
per subdirectory, etc.).
The current implementation is based on the asset browser, which in
practice means that the asset browser owns the `AssetCatalogService`
instance for the selected asset library. In the future these instances
will be accessible via a less UI-bound asset system.
The UI is still very rudimentary, only showing the catalog ID for the
currently selected asset. Most notably, the loaded catalogs are not
shown yet. The UI is being implemented and will be merged soon.
#### Catalog Identifiers
Catalogs are internally identified by UUID. In older designs this was a
human-readable name, which has the problem that it has to be kept in
sync with its semantics (so when renaming a catalog from X to Y, the
UUID can be kept the same).
Since UUIDs don't communicate any human-readable information, the
mapping from catalog UUID to its path (stored in the Catalog Definition
File, CDF) is critical for understanding which asset is stored in which
human-readable catalog. To make this less critical, and to allow manual
data reconstruction after a CDF is lost/corrupted, each catalog also has
a "simple name" that's stored along with the UUID. This is also stored
on each asset, next to the catalog UUID.
#### Writing to Disk
Before saving asset catalogs to disk, the to-be-overwritten file gets
inspected. Any new catalogs that are found thre are loaded to memory
before writing the catalogs back to disk:
- Changed catalog path: in-memory data wins
- Catalogs deleted on disk: they are recreated based on in-memory data
- Catalogs deleted in memory: deleted on disk as well
- New catalogs on disk: are loaded and thus survive the overwriting
#### Tree Design
This implements the initial tree structure to load catalogs into. See
T90608, and the basic design in T90066.
Reviewed By: Severin
Maniphest Tasks: T91552
Differential Revision: https://developer.blender.org/D12589
2021-09-23 14:56:45 +02:00
|
|
|
{
|
|
|
|
|
asset_data->catalog_id = BLI_uuid_nil();
|
|
|
|
|
asset_data->catalog_simple_name[0] = '\0';
|
|
|
|
|
}
|
|
|
|
|
|
2023-06-03 08:36:28 +10:00
|
|
|
void BKE_asset_metadata_catalog_id_set(AssetMetaData *asset_data,
|
2021-09-23 17:55:43 +02:00
|
|
|
const ::bUUID catalog_id,
|
Assets: add Asset Catalog system
Catalogs work like directories on disk (without hard-/symlinks), in that
an asset is only contained in one catalog.
See T90066 for design considerations.
#### Known Limitations
Only a single catalog definition file (CDF), is supported, at
`${ASSET_LIBRARY_ROOT}/blender_assets.cats.txt`. In the future this is
to be expanded to support arbitrary CDFs (like one per blend file, one
per subdirectory, etc.).
The current implementation is based on the asset browser, which in
practice means that the asset browser owns the `AssetCatalogService`
instance for the selected asset library. In the future these instances
will be accessible via a less UI-bound asset system.
The UI is still very rudimentary, only showing the catalog ID for the
currently selected asset. Most notably, the loaded catalogs are not
shown yet. The UI is being implemented and will be merged soon.
#### Catalog Identifiers
Catalogs are internally identified by UUID. In older designs this was a
human-readable name, which has the problem that it has to be kept in
sync with its semantics (so when renaming a catalog from X to Y, the
UUID can be kept the same).
Since UUIDs don't communicate any human-readable information, the
mapping from catalog UUID to its path (stored in the Catalog Definition
File, CDF) is critical for understanding which asset is stored in which
human-readable catalog. To make this less critical, and to allow manual
data reconstruction after a CDF is lost/corrupted, each catalog also has
a "simple name" that's stored along with the UUID. This is also stored
on each asset, next to the catalog UUID.
#### Writing to Disk
Before saving asset catalogs to disk, the to-be-overwritten file gets
inspected. Any new catalogs that are found thre are loaded to memory
before writing the catalogs back to disk:
- Changed catalog path: in-memory data wins
- Catalogs deleted on disk: they are recreated based on in-memory data
- Catalogs deleted in memory: deleted on disk as well
- New catalogs on disk: are loaded and thus survive the overwriting
#### Tree Design
This implements the initial tree structure to load catalogs into. See
T90608, and the basic design in T90066.
Reviewed By: Severin
Maniphest Tasks: T91552
Differential Revision: https://developer.blender.org/D12589
2021-09-23 14:56:45 +02:00
|
|
|
const char *catalog_simple_name)
|
|
|
|
|
{
|
|
|
|
|
asset_data->catalog_id = catalog_id;
|
|
|
|
|
|
|
|
|
|
constexpr size_t max_simple_name_length = sizeof(asset_data->catalog_simple_name);
|
|
|
|
|
|
|
|
|
|
/* The substr() call is necessary to make copy() copy the first N characters (instead of refusing
|
|
|
|
|
* to copy and producing an empty string). */
|
|
|
|
|
StringRef trimmed_id =
|
|
|
|
|
StringRef(catalog_simple_name).trim().substr(0, max_simple_name_length - 1);
|
|
|
|
|
trimmed_id.copy(asset_data->catalog_simple_name, max_simple_name_length);
|
|
|
|
|
}
|
|
|
|
|
|
2021-10-25 08:02:08 -03:00
|
|
|
void BKE_asset_metadata_idprop_ensure(AssetMetaData *asset_data, IDProperty *prop)
|
|
|
|
|
{
|
|
|
|
|
if (!asset_data->properties) {
|
|
|
|
|
IDPropertyTemplate val = {0};
|
|
|
|
|
asset_data->properties = IDP_New(IDP_GROUP, &val, "AssetMetaData.properties");
|
|
|
|
|
}
|
|
|
|
|
/* Important: The property may already exist. For now just allow always allow a newly allocated
|
|
|
|
|
* property, and replace the existing one as a way of updating. */
|
|
|
|
|
IDP_ReplaceInGroup(asset_data->properties, prop);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
IDProperty *BKE_asset_metadata_idprop_find(const AssetMetaData *asset_data, const char *name)
|
|
|
|
|
{
|
|
|
|
|
if (!asset_data->properties) {
|
|
|
|
|
return nullptr;
|
|
|
|
|
}
|
|
|
|
|
return IDP_GetPropertyFromGroup(asset_data->properties, name);
|
|
|
|
|
}
|
|
|
|
|
|
2020-12-11 23:16:29 +01:00
|
|
|
/* Queries -------------------------------------------- */
|
|
|
|
|
|
2022-10-03 17:37:25 -05:00
|
|
|
PreviewImage *BKE_asset_metadata_preview_get_from_id(const AssetMetaData * /*asset_data*/,
|
2020-12-11 23:16:29 +01:00
|
|
|
const ID *id)
|
|
|
|
|
{
|
|
|
|
|
return BKE_previewimg_id_get(id);
|
|
|
|
|
}
|
|
|
|
|
|
2020-12-11 18:15:25 +01:00
|
|
|
/* .blend file API -------------------------------------------- */
|
|
|
|
|
|
|
|
|
|
void BKE_asset_metadata_write(BlendWriter *writer, AssetMetaData *asset_data)
|
|
|
|
|
{
|
|
|
|
|
BLO_write_struct(writer, AssetMetaData, asset_data);
|
|
|
|
|
|
|
|
|
|
if (asset_data->properties) {
|
|
|
|
|
IDP_BlendWrite(writer, asset_data->properties);
|
|
|
|
|
}
|
2021-10-25 13:48:48 +02:00
|
|
|
if (asset_data->author) {
|
|
|
|
|
BLO_write_string(writer, asset_data->author);
|
|
|
|
|
}
|
2020-12-11 18:15:25 +01:00
|
|
|
if (asset_data->description) {
|
|
|
|
|
BLO_write_string(writer, asset_data->description);
|
|
|
|
|
}
|
2023-03-07 18:22:43 +01:00
|
|
|
if (asset_data->copyright) {
|
|
|
|
|
BLO_write_string(writer, asset_data->copyright);
|
|
|
|
|
}
|
|
|
|
|
if (asset_data->license) {
|
|
|
|
|
BLO_write_string(writer, asset_data->license);
|
|
|
|
|
}
|
|
|
|
|
|
2020-12-11 18:15:25 +01:00
|
|
|
LISTBASE_FOREACH (AssetTag *, tag, &asset_data->tags) {
|
|
|
|
|
BLO_write_struct(writer, AssetTag, tag);
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
void BKE_asset_metadata_read(BlendDataReader *reader, AssetMetaData *asset_data)
|
|
|
|
|
{
|
|
|
|
|
/* asset_data itself has been read already. */
|
2021-10-25 08:02:08 -03:00
|
|
|
asset_data->local_type_info = nullptr;
|
2020-12-11 18:15:25 +01:00
|
|
|
|
|
|
|
|
if (asset_data->properties) {
|
|
|
|
|
BLO_read_data_address(reader, &asset_data->properties);
|
|
|
|
|
IDP_BlendDataRead(reader, &asset_data->properties);
|
|
|
|
|
}
|
|
|
|
|
|
2021-10-25 13:48:48 +02:00
|
|
|
BLO_read_data_address(reader, &asset_data->author);
|
2020-12-11 18:15:25 +01:00
|
|
|
BLO_read_data_address(reader, &asset_data->description);
|
2023-03-07 18:22:43 +01:00
|
|
|
BLO_read_data_address(reader, &asset_data->copyright);
|
|
|
|
|
BLO_read_data_address(reader, &asset_data->license);
|
2020-12-11 18:15:25 +01:00
|
|
|
BLO_read_list(reader, &asset_data->tags);
|
|
|
|
|
BLI_assert(BLI_listbase_count(&asset_data->tags) == asset_data->tot_tags);
|
|
|
|
|
}
|