Simple implementation of an AssetCatalogService that's responsible
for managing asset catalogs and loading them from asset *catalog definition
files* (CDFs).
The following classes are implemented in this patch:
- struct AssetLibrary: an opaque struct that C code can just pass around; it is actually defined in C++. It is created with BKE_asset_library_load(library_path) and freed with BKE_asset_library_free(the_pointer). It has an owning pointer to a AssetCatalogService, which is also created from the BKE_asset_library_load() call.
- AssetCatalogService: a C++ class that is responsible for managing asset catalogs of a single asset library. A future version will be able to load multiple catalog definition files and join the catalogs defined therein; this version only loads a single file, single_catalog_definition_file.cats.txt, from the top directory of the asset library.
- AssetCatalogDefinitionFile: representation of the file the AssetCatalogs were loaded from. This is mostly important for supporting multiple CDFs; when their catalogs change, it should be known which files they came from.
- AssetCatalog: contains the catalog ID and the full catalog path.
Features
The following features are implemented here:
- Added field char AssetMetaData::catalog_id[MAX_NAME], to hold the catalog ID of the asset. This field should be set using the BKE_asset_metadata_catalog_id_set() function, which ensures that there are no spaces in the ID and that the field is not too long.
- A little UI extension to show the active asset's catalog ID in the asset browser.
- Loading a single CDF
- Parsing the CDF into AssetCatalog structs
- The AssetCatalogService::find_catalog(catalog_id) method, which returns the AssetCatalog identified by the given ID.
- Creating an AssetCatalogDefinitionFile, which can also save the catalogs back to disk (in arbitrary order)
- Creating & storing an AssetLibrary in the FileList struct, to be able to find & parse the CDFs in a background thread.
Future work
After this patch is accepted, the following work should be done:
- Change from std::filesystem to another library, depending on the outcome of D12117: Initial work for std::filesystem transition
- Provide a hierarchical view on catalogs, such that a tree can be drawn in the UI
- Provide an API for renaming catalogs, both their ID and their path.
- Save catalogs to the catalog definition file, ordered by their path. This'll make the order in which they are saved predictable & stable, playing nice with versioning systems.