Blender Git Commits

Blender Git "temp-pose-flipping-fix-attempt" branch commits.

Page: 12 / 16

March 19, 2021, 16:09 (GMT)
Fix race condition when multiple file/asset-lists are running at once

E.g. opening a file with an asset viewer and an Asset Browser could cause one
of them to not load its files properly. That is because there was only one
`wmJob` per scene so when the first one was done it would end the other one(s).
I think this would be a problem in master for the regular File Browser too.

Instead of setting the scene as owner of the job, use the file-list, so that
each file/asset-list gets its own job.
March 18, 2021, 18:47 (GMT)
Cleanup: First round of polishing (C++ style, type safety, naming, etc)

* Follow "rule of five"
* Explicit conversion constructors
* Separate inteface declarations from definitions (readability)
* Avoid clang-tidy error
* Naming
....
March 18, 2021, 14:48 (GMT)
Merge branch 'ui-asset-view-template' into asset-browser-poselib
March 18, 2021, 14:30 (GMT)
Merge branch 'master' into ui-asset-view-template
March 18, 2021, 13:44 (GMT)
Pose Library: use the new temp-loading functions in the blenloader module
March 18, 2021, 13:44 (GMT)
Cleanup: pose lib, clarify comment
March 18, 2021, 13:43 (GMT)
Merge remote-tracking branch 'origin/master' into asset-browser-poselib

# Conflicts:
# source/blender/blenloader/intern/versioning_290.c
March 17, 2021, 19:51 (GMT)
Use custom collection property to pass the asset list to UI lists

`UIList` is designed to use collection properties. I previously did a
whole bunch of hacks to use it without. This isn't acceptable for
master, instead a proper collection property should be provided.

Idea is to let scripts register a custom collection property, that the
asset view template can fill with the latest asset list contents and
pass that to the UI list.

Longer term I'd prefer if the UI code would support other containers,
and not rely so much on RNA and custom/ID properties. I have ideas and
plans for this, but meanwhile, this will do to remove the hacks.
March 17, 2021, 12:56 (GMT)
Fix warning about possibly mixed C/C++ linkage of type

Would give a warning:
```
'ED_asset_library_reference_from_enum_value' has C-linkage specified, but
returns incomplete type 'struct AssetLibraryReference' which could be
incompatible with C [-Wreturn-type-c-linkage]
```
March 16, 2021, 16:38 (GMT)
Construct-on-first-use to stay far away from static init. fiasco

We didn't actually run into the static initialization fiasco, but only
because `blender::Map` didn't use the guarded allocator on default
destruction. Better to stay far way from static initialization fiasco,
and the construct on first use idiom is trivial and prevents it. So
better use that.
March 16, 2021, 15:45 (GMT)
Merge branch 'ui-asset-view-template' into asset-browser-poselib
March 16, 2021, 15:44 (GMT)
Fix asset storage crash when closing Blender in release mode
March 16, 2021, 14:45 (GMT)
Use custom .py property for active asset index, stored in the workspace

Previously I just used the active color index of the first palette to
get things to work.
I would've preferred if the asset view template could register own
properties and store them in the `UIList` it creates. That way you could
have multiple asset views with entirely independent data. But since this
isn't possible, we need a different way to store such data, I think the
workspace makes sense. It should still be possible to store different
data for different use-cases, e.g. to show a pose asset list in pose
mode and a material asset list in object mode. So idea is to let
scripts/add-ons register custom properties for their specific use case
(e.g. "Active Pose Asset" for the pose libraries).
March 16, 2021, 14:43 (GMT)
Use custom .py property for active asset index, stored in the workspace

Previously I just used the active color index of the first palette to
get things to work.
I would've preferred if the asset view template could register own
properties and store them in the `UIList` it creates. That way you could
have multiple asset views with entirely independent data. But since this
isn't possible, we need a different way to store such data, I think the
workspace makes sense. It should still be possible to store different
data for different use-cases, e.g. to show a pose asset list in pose
mode and a material asset list in object mode. So idea is to let
scripts/add-ons register custom properties for their specific use case
(e.g. "Active Pose Asset" for the pose libraries).
March 16, 2021, 14:01 (GMT)
Pose library: remove invalid flags

The wrong flags were used, and it works fine without flags as well.

No functional changes.
March 16, 2021, 12:11 (GMT)
Merge branch 'ui-asset-view-template' into asset-browser-poselib
March 16, 2021, 12:06 (GMT)
Store active asset library at workspace level

The Asset Browser still has its own active asset library. But for the UI
(e.g. the asset view UI template), there is one active asset library per
workspace now. This is needed because for technical reasons the property
has to be registered in C, ideally you could just register it as custom
property for any use-case and pass that to the asset view template.
Since this isn't possible, an active asset library per workspace seems
reasonable.
March 16, 2021, 10:56 (GMT)
Merge remote-tracking branch 'origin/master' into asset-browser-poselib
March 16, 2021, 10:43 (GMT)
Merge branch 'master' into ui-asset-view-template
March 16, 2021, 10:43 (GMT)
Pose Library: get initial blend factor from RNA property
By: Miika HämäläinenLast update: Nov-07-2014 14:18MiikaHweb | 2003-2021