Age | Commit message (Collapse) | Author |
|
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
|
|
Use "filepath" which is the current convention for naming full paths.
- Main use "name" which isn't obviously a file path.
- BlendFileData & FileGlobal used "filename" which is often
used for the name component of a path (without the directory).
|
|
Also move system includes first, like we have it elsewhere in Blender.
|
|
Keep track of unsaved asset catalog changes, in a more granular way than
just one boolean per asset library. Individual catalogs can now be
marked with a flag `has_unsaved_changes`. This is taken into account
when reloading data from the catalog definition file (CDF):
- New catalog in CDF: gets loaded
- Already-known catalog in CDF:
- local unsaved changes: on-disk catalog is ignored
- otherwise: on-disk catalog replaces in-memory one
- Already-known catalog that does not exist in CDF:
- local unsaved changes: catalog is kept around
- otherwise: catalog is deleted.
Because this saving-is-also-loading behaviour, the "has unsaved changes"
flags are all stored in the undo buffer; undoing after saving will not
change the CDF, but at least it'll undo the loading from disk, and it'll
re-mark any changes as "not saved".
Reviewed By: Severin
Differential Revision: https://developer.blender.org/D12967
|
|
No longer save asset catalogs on blendfile save. Instead:
- extend the confirmation prompt for unsaved changes to show unsaved
catalogs.
- In the confirmation prompt, make catalog saving explicit & optional,
just like we do it for external images. {F10881736}
- In the Asset Browser catalog tree, show an operator icon to save the
catalogs to disk. It's grayed out if there are no changes to save, or
if the .blend wasn't saved yet (required to know where to save the
catalog definitions to). {F10881743}
Much of the work was done by @Severin and reviewed by me, then we
swapped roles.
Reviewed By: Severin
Differential Revision: https://developer.blender.org/D12796
|
|
Allow creating a new asset catalog in a yet-to-be-saved blend file. The
problem was caused by `AssetLibrary` not having an `AssetCatalogService`
right after creation; only after loading data from disk was this
instance created. It's now always there.
|
|
Add `blender::bke::AssetLibraryService` class that acts like a
blendfile-scoped singleton. It's allocated upon the first call to
`BKE_asset_library_load` and destroyed in the LOAD-PRE handler.
The `AssetLibraryService` ensures that edits to asset catalogs are not
lost when the asset browser editor closes (or even reloads). Instead,
the `AssetLibrary` pointers it owns are kept around as long as the blend
file is open.
Reviewed By: Severin
Maniphest Tasks: T92151
Differential Revision: https://developer.blender.org/D12885
|
|
When assigning a new catalog ID to an asset, also refresh the "catalog
simple name". This "simple name" is stored on the asset metadata next to
the catalog UUID, to allow some emergency data recovery when the catalog
definition file is somehow lost.
|
|
The Asset Browser now displays a tree with asset catalogs in the left
sidebar.
This replaces the asset categories. It uses the new UI tree-view API
(https://wiki.blender.org/wiki/Source/Interface/Views#Tree-View).
Buttons are displayed for adding and removing of catalogs. Parent items
can be collapsed, but the collapsed/uncollapsed state is not stored in
files yet.
Note that edits to catalogs (e.g. new or removed catalogs) are only
written to the asset library's catalog definition files when saving a
.blend.
In the "Current File" asset library, we try to show asset catalogs from
a parent asset library, or if that fails, from the directory the file is
stored in. See adaf4f56e1ed.
There are plenty of TODOs and smaller glitches to be fixed still. Plus a
UI polishing pass should be done.
Important missing UI features:
* Dragging assets into catalogs (WIP, close to being ready).
* Renaming catalogs
* Proper handling of catalogs in the "Current File" asset library
(currently not working well).
The "Current File" asset library is especially limited still. Since this
is the only place where you can assign assets to a catalog, this makes
the catalogs very cumbersome in general. To assign an asset to a
catalog, one has to manually copy the Catalog ID (a random hash like
number) to the asset metadata through a temporary UI in the Asset
Browser Sidebar. These limitations should be addressed over the next few
days, they are high priority.
Differential Revision: https://developer.blender.org/D12670
|
|
When the Asset Browser shows the "Current File" asset library, now it
also attempts to load an asset catalog definition file from location of
the current .blend file. This happens as follows:
* First, see if the file is inside of an asset library that is "mounted" in the
Preferences. Load the catalogs from there if so.
* Otherwise, if the file is saved, load the catalogs from the directory the
file is saved in.
* If the file is not saved, no catalogs will be loaded.
Unit tests are being worked on in D12689.
Creating catalogs from the "Current File" asset library still doesn't work, as
the asset catalog service doesn't construct an in-memory catalog definition
file in that case yet.
Differential Revision: https://developer.blender.org/D12675
|
|
Found by clang tidy (P2439).
|
|
The Asset Catalog Definition File is now saved whenever the blend file
is saved. The location of the CDF depends on where the blend file is
saved, and whether previously a CDF was already loaded, according to the
following rules. The first matching rule wins:
1. Already loaded a CDF from disk? -> Always write to that file.
2. The directory containing the blend file has a
`blender_assets.cats.txt` file? -> Merge with & write to that file.
3. The directory containing the blend file is part of an asset library,
as per the user's preferences? -> Merge with & write to
`${ASSET_LIBRARY_ROOT}/blender_assets.cats.txt`
4. Create a new file `blender_assets.cats.txt` next to the blend file.
|
|
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
|