Accessing `bl_rna` for type defined in `scripts/modules/bpy_types.py`
could return their parent-classes RNA when accessed via their parent
types __subclasses__() method.
The type of an RNA types "bl_rna" should be `bpy.types.Struct`,
it was being set to the type it represented so:
`type(bpy.types.Object.bl_rna) == bpy.types.Object`
which wasn't correct.
Ref !126877
Co-authored-by: Bastien Montagne <bastien@blender.org>
Use snake style naming for all the kernel nodes functions.
Omit kernel prefix in the names since of the using namespace.
Use full forms of the terms
('iter' -> 'iterator', 'ntree' -> 'node_tree', 'rem' -> 'remove', ...).
Pull Request: https://projects.blender.org/blender/blender/pulls/126416
Previously, values for `ID.flag` and `ID.tag` used the prefixes `LIB_` and
`LIB_TAG` respectively. This was somewhat confusing because it's not really
related to libraries in general. This patch changes the prefix to `ID_FLAG_` and
`ID_TAG_`. This makes it more obvious what they correspond to, simplifying code.
Pull Request: https://projects.blender.org/blender/blender/pulls/125811
Calling `foreach_get/set` on a collection property did not trigger
a property update. In the attribute API, this lead to missing
updates after e.g. setting the values of an attribute.
This adds a call to `RNA_property_update` for the getter/setter
bpy rna function and adds a property update callback to all the
different attribute collection properties.
Pull Request: https://projects.blender.org/blender/blender/pulls/125518
This commit moves generated `RNA_blender.h`, `RNA_prototype.h` and
`RNA_blender_cpp.h` headers to become C++ header files.
It also removes the now useless `RNA_EXTERN_C` defines, and just
directly use the `extern` keyword. We do not need anymore `extern "C"`
declarations here.
Pull Request: https://projects.blender.org/blender/blender/pulls/124469
Sometimes it is necessary to pass additional data through generic UI entities,
to specific implementations. For example to pass additional options to panel
polling & drawing when instantiating a panel through its panel type. Or storing
additional data in a button, without hardcoding it in the button struct/class.
Passing data via context is a simple solution to this, however so far this only
works using hardcoded context queries or RNA pointers. For passing arbitrary
strings we've used workarounds like creating an RNA type to wrap it already.
For example `RNA_AssetCatalogPath`, which is used to dynamically populate menu
items based on an asset catalog path, via a generic menu type.
type instantiation. This makes it possible to invoke specific asset shelves as
popover panels.
Idea is simply to let `bContextStore` entries hold copies of the string (as
`std::string`), avoiding lifetime issues. Context APIs are extended to support
setting/querying strings via a context member name.
Pull Request: https://projects.blender.org/blender/blender/pulls/122113
Move all header file into namespace.
Unnecessary namespaces was removed from implementations file.
Part of forward declarations in header was moved in the top part
of file just to do not have a lot of separate namespaces.
Pull Request: https://projects.blender.org/blender/blender/pulls/121637
Previously retrieving a collection from the context like "selected_ids"
would give a linked list of allocated items. Now it returns a vector of
RNA pointers. Though the number of items is typically fairly small,
using contiguous memory and avoiding many small allocations are
typical performance improvements that could still be beneficial
when there are many items. Iteration also becomes much simpler.
Pull Request: https://projects.blender.org/blender/blender/pulls/119939
Python's behavior changed since this feature was added causing the
object to be tracked when freed by Python's subtype_dealloc even
if Blender has not tracked the data. Detect this case and untrack
the object before freeing.
Accessing `__class__` on a removed object raised an exception, making
`isinstance(ob, cls)` unreliable. Always allow class access.
Resolves issue raised by blender/blender-addons!104958.
This significantly simplifies memory management, mostly by avoiding
the need to free the memory manually. It may also improve performance,
since std::string has an inline buffer that can prevent heap
allocations and it stores the size.
Pull Request: https://projects.blender.org/blender/blender/pulls/117695
Recent and ongoing efforts have changed many properties to be stored
contiguously in memory, e.g. mesh attributes. This patch updates
rna_raw_access to make use of this and copy the entire contiguous block
of memory when the property is stored contiguously.
This is faster and scales much better with larger arrays.
Pull Request: https://projects.blender.org/blender/blender/pulls/116015
The foreach_get/foreach_set methods of bpy_prop_array get/set the entire
contents of the array, but they were checking that the length of the
input sequence was equal to the length of the current array dimension
rather than the total length of all dimensions of the array.
This would read/write memory after the end of the passed in sequence
when the property was a multidimensional array. Performing
`foreach_get` with a Python list with length matching the length of the
current dimension of a multidimensional array would crash a debug build
due to the trailing pad bytes of the temporarily allocated array being
overwritten.
This patch fixes `pyprop_array_foreach_getset` by changing the function
used to get the expected sequence size, to the RNA function that gets
the total length of the array across all its dimensions.
The tests have be updated to additionally test multidimensional array
properties.
Pull Request: https://projects.blender.org/blender/blender/pulls/116457
RNA raw types were missing for the int8_t, uchar (uint8_t),
ushort (uint16_t), int64_t and uint64_t DNA types types.
This adds the missing RNA raw types for all DNA types that can have
raw access.
Functional Changes
Properties with one of the new unsigned raw types will raise a Python
OverflowError in foreach_getset when attempting to read a negative
integer from bpy_prop_collection.foreach_set(). This is similar to the
existing behaviour of providing a Python int which is too large to
represent as a C long. The existing foreach_getset code will print
the OverflowError and then raise a TypeError instead.
CPython's signed integer parsing functions accept numeric types that are
not the Python int instances by calling their __index__() method.
CPython's unsigned integer parsing functions, however, only accept
Python int instances. To make foreach_getset accept the same
numeric types for unsigned raw types as it already accepts for signed
raw types, the unsigned integer parsing functions in py_capi_utils.h
have been updated to also call the __index__() method when given an
argument which is not a Python int instance.
Because the new unsigned integer parsing in foreach_getset is using
the PyC_ family of functions, which perform their own overflow checks,
the existing signed integer parsing has also been updated to use the
PyC_ family of functions for signed integer parsing. Previously,
OverflowError would only have been raised when the parsed integer was
too large to fit in a C long. With this patch, OverflowError will be
raised whenever the parsed integer is too large to fit in the property's
raw type. Integer properties already have well-defined maximum and
minimum values which should fit within the property's raw type, and enum
properties have a fixed number of values they can take depending on
their items. The bigger change here, is that setting bool properties
which use PROP_RAW_BOOLEAN will now only accept 0/False and
1/True.
Now that PROP_RAW_CHAR parsing is using PyC_Long_AsU8,
signed char buffers ("b" format) have been updated to no longer be
considered compatible with PROP_RAW_CHAR, matching the behaviour of
the other unsigned types only being considered compatible with unsigned
buffer formats.
The int64_t and uint64_t types can currently only be used by bool
properties (see IS_DNATYPE_BOOLEAN_COMPAT and the other macros in
RNA_define.hh), but bool properties only have raw access when they do
not use a bitmask and it doesn't make much sense to use an entire 64
bits just for a single bool property, so PROP_RAW_INT64 and
PROP_RAW_UINT64 are expected to be unused.
Performance Changes
Providing raw types allows for faster access through
rna_access.cc#rna_raw_access, especially when a buffer compatible with
the property's raw type is passed through from
bpy_rna.cc#foreach_getset.
Before this patch, the bpy.types.Keyframe.handle_left_type property
did not have raw access, so foreach_getset would fall back to
PROP_RAW_INT being the compatible type and then use the slower loop in
rna_raw_access.
With this patch, the bpy.types.Keyframe.handle_left_type property has
raw access with the PROP_RAW_UINT8 type. Using a buffer compatible
with this raw type can use the faster memcpy loop in
rna_raw_access. Using a Python list will iterate the list into an
array whose type matches PROP_RAW_UINT8, which will also use the
faster memcpy loop in #rna_raw_access.
Pull Request: https://projects.blender.org/blender/blender/pulls/115761
RNA raw types were missing for the int8_t, uchar (uint8_t),
ushort (uint16_t), int64_t and uint64_t DNA types types.
This adds the missing RNA raw types for all DNA types that can have
raw access.
Functional Changes
Properties with one of the new unsigned raw types will raise a Python
OverflowError in foreach_getset when attempting to read a negative
integer from bpy_prop_collection.foreach_set(). This is similar to the
existing behaviour of providing a Python int which is too large to
represent as a C long. The existing foreach_getset code will print
the OverflowError and then raise a TypeError instead.
CPython's signed integer parsing functions accept numeric types that are
not the Python int instances by calling their __index__() method.
CPython's unsigned integer parsing functions, however, only accept
Python int instances. To make foreach_getset accept the same
numeric types for unsigned raw types as it already accepts for signed
raw types, the unsigned integer parsing functions in py_capi_utils.h
have been updated to also call the __index__() method when given an
argument which is not a Python int instance.
Because the new unsigned integer parsing in foreach_getset is using
the PyC_ family of functions, which perform their own overflow checks,
the existing signed integer parsing has also been updated to use the
PyC_ family of functions for signed integer parsing. Previously,
OverflowError would only have been raised when the parsed integer was
too large to fit in a C long. With this patch, OverflowError will be
raised whenever the parsed integer is too large to fit in the property's
raw type. Integer properties already have well-defined maximum and
minimum values which should fit within the property's raw type, and enum
properties have a fixed number of values they can take depending on
their items. The bigger change here, is that setting bool properties
which use PROP_RAW_BOOLEAN will now only accept 0/False and
1/True.
Now that PROP_RAW_CHAR parsing is using PyC_Long_AsU8,
signed char buffers ("b" format) have been updated to no longer be
considered compatible with PROP_RAW_CHAR, matching the behaviour of
the other unsigned types only being considered compatible with unsigned
buffer formats.
The int64_t and uint64_t types can currently only be used by bool
properties (see IS_DNATYPE_BOOLEAN_COMPAT and the other macros in
RNA_define.hh), but bool properties only have raw access when they do
not use a bitmask and it doesn't make much sense to use an entire 64
bits just for a single bool property, so PROP_RAW_INT64 and
PROP_RAW_UINT64 are expected to be unused.
Performance Changes
Providing raw types allows for faster access through
rna_access.cc#rna_raw_access, especially when a buffer compatible with
the property's raw type is passed through from
bpy_rna.cc#foreach_getset.
Before this patch, the bpy.types.Keyframe.handle_left_type property
did not have raw access, so foreach_getset would fall back to
PROP_RAW_INT being the compatible type and then use the slower loop in
rna_raw_access.
With this patch, the bpy.types.Keyframe.handle_left_type property has
raw access with the PROP_RAW_UINT8 type. Using a buffer compatible
with this raw type can use the faster memcpy loop in
rna_raw_access. Using a Python list will iterate the list into an
array whose type matches PROP_RAW_UINT8, which will also use the
faster memcpy loop in #rna_raw_access.
Pull Request: https://projects.blender.org/blender/blender/pulls/115761
Adds initial support for File Handler registration with the python API
for design task #68935. File Handlers will allow developers to associate
additional UI behavior and capability to operators traditionally used
only within the file browser.
The initial commit should have no user visible changes, but will serve
as the foundation for providing file drag & drop capabilities to
operators that can manage files (#111242).
See the PR for an example of python usage.
See design task #68935 for remaining work to be explored in the future.
Pull Request: https://projects.blender.org/blender/blender/pulls/112466
NDEBUG is part of the C standard and disables asserts. Only this will
now be used to decide if asserts are enabled.
DEBUG was a Blender specific define, that has now been removed.
_DEBUG is a Visual Studio define for builds in Debug configuration.
Blender defines this for all platforms. This is still used in a few
places in the draw code, and in external libraries Bullet and Mantaflow.
Pull Request: https://projects.blender.org/blender/blender/pulls/115774
Resolves#115090, where exceptions from the text editor called
`sys.excepthook` in v3.6 but not in v4.0.
The error was caused by PyC_ExceptionBuffer calling PyErr_Display
instead of PyErr_Print.
While technically a regression in [0], the behavior in 3.6x wasn't
working properly either since a user-defined `sys.excepthook` could
prevent PyC_ExceptionBuffer from accessing the exception text.
Resolve with the following changes:
- BPy_errors_to_report has been updated not to print errors.
Previously BPy_errors_to_report would *sometimes* print the error,
which complicated situations where the caller wanted predictable
behavior (always printing or never printing).
- `PyErr_Print()` must be used to display errors to the output,
this will call `sys.excepthook` as it used to.
It's better not to rely on side effects of BPy_errors_to_report()
for error handling.
[0]: 6a0f98aeef
