Python 3.14 has moved some functionality into the public API,
use the updated names even with older Python versions.
Also resolve an error caused by variable reuse with delayed annotation
evaluation for TextureProperties_MixIn on startup.
Resolve#140695.
The main issue of 'type-less' standard C allocations is that there is no check on
allocated type possible.
This is a serious source of annoyance (and crashes) when making some
low-level structs non-trivial, as tracking down all usages of these
structs in higher-level other structs and their allocation is... really
painful.
MEM_[cm]allocN<T> templates on the other hand do check that the
given type is trivial, at build time (static assert), which makes such issue...
trivial to catch.
NOTE: New code should strive to use MEM_new (i.e. allocation and
construction) as much as possible, even for trivial PoD types.
Pull Request: https://projects.blender.org/blender/blender/pulls/135852
The general idea is to keep the 'old', C-style MEM_callocN signature, and slowly
replace most of its usages with the new, C++-style type-safer template version.
* `MEM_cnew<T>` allocation version is renamed to `MEM_callocN<T>`.
* `MEM_cnew_array<T>` allocation version is renamed to `MEM_calloc_arrayN<T>`.
* `MEM_cnew<T>` duplicate version is renamed to `MEM_dupallocN<T>`.
Similar templates type-safe version of `MEM_mallocN` will be added soon
as well.
Following discussions in !134452.
NOTE: For now static type checking in `MEM_callocN` and related are slightly
different for Windows MSVC. This compiler seems to consider structs using the
`DNA_DEFINE_CXX_METHODS` macro as non-trivial (likely because their default
copy constructors are deleted). So using checks on trivially
constructible/destructible instead on this compiler/system.
Pull Request: https://projects.blender.org/blender/blender/pulls/134771
When using clangd or running clang-tidy on headers there are
currently many errors. These are noisy in IDEs, make auto fixes
impossible, and break features like code completion, refactoring
and navigation.
This makes source/blender headers work by themselves, which is
generally the goal anyway. But #includes and forward declarations
were often incomplete.
* Add #includes and forward declarations
* Add IWYU pragma: export in a few places
* Remove some unused #includes (but there are many more)
* Tweak ShaderCreateInfo macros to work better with clangd
Some types of headers still have errors, these could be fixed or
worked around with more investigation. Mostly preprocessor
template headers like NOD_static_types.h.
Note that that disabling WITH_UNITY_BUILD is required for clangd to
work properly, otherwise compile_commands.json does not contain
the information for the relevant source files.
For more details see the developer docs:
https://developer.blender.org/docs/handbook/tooling/clangd/
Pull Request: https://projects.blender.org/blender/blender/pulls/132608
It would crash with no `id_type` specified.
Custom Properties Datablock Pointers were introduced in the UI in
b3c7f3c8a9.
When created via python, we dont enforce a `id_type`, when done via the
UI, this should be set though. However, I think when using `update()`,
the `id_type` is optional, so should be possible to just change the
`description` for example and leave the type untouched.
Code was trying to get the id type from the string passed in (None in
this case) and crashed somewhere along the way of
`pyrna_enum_value_from_id` which such NULL string.
So to resolve, just leave the `id_type` untouched if nothing is
specified here.
Pull Request: https://projects.blender.org/blender/blender/pulls/122306
This is an optional parameter for int properties, which then show up as
enum properties.
Included fix: reset ID properties' enum items when the `items` parameter is `None`.
Example usage:
```python
import rna_prop_ui
# Add a regular int property.
rna_prop_ui.rna_idprop_ui_create(D.objects['Cube'], "test", default=123, min=-3, max=500)
# Change to an enum property with items (min/max are ignored).
rna_prop_ui.rna_idprop_ui_create(D.objects['Cube'], "test", default=0, min=-10, max=10, items=[("APPLES", "Apples", ""), ("ORANGES", "Oranges", "")])
# Switch back to regular int property.
rna_prop_ui.rna_idprop_ui_create(D.objects['Cube'], "test", default=1, min=0, max=10)
```
Pull Request: https://projects.blender.org/blender/blender/pulls/117289
`PyArg_ParseTupleAndKeywords` does not initialize variable corresponding
to optional arguments that aren't passed by Python. Thanks to Germano for
initial investigation.
Add support for enum values in ID properties.
This is needed for the "Menu Switch" node implementation (#113445) which
relies on ID properties for the top-level modifier UI.
Enums items can optionally be added to the UI data of integer
properties. Each property stores a full set of the enum items to keep
things simple.
Enum items can be added to properties using the `id_properties_ui`
function in the python API. A detailed example can be found in the
`bl_pyapi_idprop.py` test.
There is currently no support yet for editing enum items through the UI.
This is because the "Edit Property" feature is implemented entirely
through a single operator (`WM_OT_properties_edit`) and its properties.
Buttons to add/remove/move items would be operators changing another
operator's properties. A refactor of the custom properties UI is likely
required to make this work.
Pull Request: https://projects.blender.org/blender/blender/pulls/114362
New code exposing ID Pointers CustomProperties to the UI (b3c7f3c8a9)
would cause invalid data access when calling `as_dict()` on py-defined ID
pointers ID properties, since these have no ID type defined by default.
The code of `as_dict()` will now forcefully generate a valid ID type
value, either by using the type of the currently assigned ID, or falling
back to the Object ID type.
Found while opening some lighting production files from the Pets
Project.
Customprops to IDs are supported since years through code, but were
never exposed directly in the UI of customporperties.
This commit mainly:
* Adds a new `DATA_BLOCK` type to UI customprops types.
* Exposes the existing `id_type` settings to python API.
Pull Request: https://projects.blender.org/blender/blender/pulls/110458
Listing the "Blender Foundation" as copyright holder implied the Blender
Foundation holds copyright to files which may include work from many
developers.
While keeping copyright on headers makes sense for isolated libraries,
Blender's own code may be refactored or moved between files in a way
that makes the per file copyright holders less meaningful.
Copyright references to the "Blender Foundation" have been replaced with
"Blender Authors", with the exception of `./extern/` since these this
contains libraries which are more isolated, any changed to license
headers there can be handled on a case-by-case basis.
Some directories in `./intern/` have also been excluded:
- `./intern/cycles/` it's own `AUTHORS` file is planned.
- `./intern/opensubdiv/`.
An "AUTHORS" file has been added, using the chromium projects authors
file as a template.
Design task: #110784
Ref !110783.
