Deprecation meta-data support for RNA properties.
- Properties may have a deprecated note and version.
- Warnings shown when these are accessed from Python.
- A note is included in the generated documentation.
Support for marking functions as deprecated can be added in the future.
Ref !139487
Show warnings for debug builds or when `--debug-python` is passed in.
Without this, only scripts running in the `__main__` namespace
show warnings - hiding warnings for almost all scripts & add-ons.
This is also needed so deprecation warnings can be shown, see !139487.
* Replace G.quiet by CLG_quiet_set/get
* CLOG_INFO_NOCHECK prints are now suppressed when quiet, these were
typically inside a if (!G.quiet) conditional already.
* Change some prints for blend files, color management and rendering to
use CLOG, that were previously using if (!G.quiet) printf().
Pull Request: https://projects.blender.org/blender/blender/pulls/143138
Ever since [0], ReportList is not actually used in any DNA structs.
That makes sense, since reports are conceptually only necessary
at runtime. Move the definition of the struct to BKE_report.hh, and
fix a bunch of include errors where types were previously available
transitively. Besides adding some clarity, theoretically this change
could reduce compile times because of less header parsing.
[0]: 1bf6d8b0b9
Pull Request: https://projects.blender.org/blender/blender/pulls/138872
The Python API wasn't accounting for structs name properties using
path sub-types, which allow non UTF8 byte sequences.
This meant accessing the SpaceFileBrowser.recent_folders collection
could cause unhandled exceptions because
FileBrowserFSMenuEntry.name uses the PROP_FILENAME sub-type.
Resolve by adding a wrapper around the RNA struct name lookup
that handles path properties properly.
Only major and minor versions are available at that point, not the
blendfile subversion.
Version info is available in both `bpy_library` items returned by the
context handler, as a `version` property that is a tuple of two numbers.
Co-authored-by: Campbell Barton <campbell@blender.org>
Pull Request: https://projects.blender.org/blender/blender/pulls/141462
The numeric levels have no obvious meaning. This removes the distinction
between severity and levels, instead there is a single list of named levels
with defined meaning.
Debug means information that's mainly useful for developers, and trace is for
very verbose code execution tracing.
Pull Request: https://projects.blender.org/blender/blender/pulls/140244
- Add PyObject_GetOptionalAttrString (only available in Python 3.13).
- When registering RNA classes use optional attribute access to avoid
raising and clearing exceptions.
- Refactor macro that handles substituting Python's built-ins
with a `for` loop for better readability.
If `__name__` or `__doc__` were None, the property would be detected as
being set when checking if the property is set (for required properties).
This is more of a technical correction as its unlikely developers would
run into this in practice since `__name__` should never be None and
the description is not a required property.
- `bpy_struct.id_data` - provide a type.
- `bpy_struct` - add missing return types to
`bpy_struct.get`, `bpy_struct.pop`, `bpy_struct.path_resolve`.
- `bpy_struct` - add missing argument types to some methods.
- `bpy_struct` - provide explicit `/` and `*` in signatures to make it
clear which arguments are positional / keyword-only.
Ref !141334
In most (cases functions returning a PyObject pointer
requires it to be used by the caller, declare functions in the Python
API with the `nodiscard` attribute.
Add an error check that the path being linked doesn't match the current
blend file.
Also resolve reference leak in the case of library override errors.
This commit cleanly splits IDProperties storage for its two very different
usages:
* "User-defined" data, also known as "custom properties". Mostly exposed
in UI and as 'dictionary' in Python scripting, these are unique to each data
(each object can have its own set of custom properties).
* "System-defined" data, mainly as backend-storage for runtime RNA
structures and properties. While these are not necessarily present in the
storage, they are registered for a data type, and therefore always available
to all data of that type through RNA access.
See #123232 for rationales, designs and alternative investigated solutions.
## User-facing Changes
When using Blender, the only noticeable change is that python-defined RNA
data are not listed anymore in the Custom Properties panels (e.g. Cycles
data).
From a Python API perspective, the main changes are:
* Runtime RNA structs defined by sub-classing `PropertyGroup` and
registering them are no more accessible through the 'dict' syntax.
* They remain accessible through a dedicated 'bl_system_properties_get()`
callback, but its usages are only expected to be for testing and
debugging.
* The result of this call will be `None` by default when there has been
nothing written into it yet, unless its optional `do_create` parameter
is set to `True`.
* Some types (like `Node`, `UIList`, etc.) cannot store raw IDProperties
anymore (using the 'dict' syntax).
## Technical Details
* Adds System idprops to some data types (IDs, ViewLayer...).
* Moves some other containers (e.g operator properties, or some UI types like
UILists) to only have system-defined properties.
* For a few specific types (like `PropertyGroup`), the same storage is used,
but exposed in RNA as both user and system properties.
* Adds RNA API accessor callback to system idprops.
* Adds a function `bl_system_properties_get()`, which wraps system-defined
idprops and gives 'dict-like' access to them. Currently mainly used by some
unittests.
* System IDProps are always ignored by RNA diffing code (and therefore
liboverride processing), as their value is already exposed through RNA
properties, and should always be processed through these RNA properties.
* Modifies bpy rna binding to use these new system idprops for property
accesses, and keeps using user-defined idprops for 'dict-type' accesses.
* Handles versioning by copying 'user idprops' (existing ones) into new
'system idprops'.
### IDProperties Split
These types keep their historic IDProperty storage for user properties,
and get a new `system_id_properties` storage for system properties:
`ID`, `ViewLayers`, `Bone`, `EditBone`, `BoneCollection`, `PoseBone`, `Strip`
These types can both be extended with registrable RNA properties, and
expose Custom Properties in the UI.
### IDProperties become System Ones
These types keep a single IDProperties storage (their DNA struct does not
change), but it is now exclusively used for system-defined properties.
`OperatorProperty`, `View3DShading`, `UIList`, `AddonPreferences`,
`KeyConfigPreferences`, `GizmoProperties`, `GizmoGroupProperties`,
`Node`, `NodeSocket`, `NodeTreeInterfaceSocket`, `TimelineMarker`,
`AssetMetaData``
Since user properties were never available in the UI for them, they lose
their 'dict-like' IDProperties access in the Python API.
### Single Storage, Exposed as Both in API
These types still use a single IDProperty storage, but expose it both as
user properties and as system ones through RNA API.
* `PropertyGroup`: They need both access APIs since they are both
used for raw IDProperty groups (the 'dict-like' access), and
internally to access data of runtime-defined RNA structs.
* `IDPropertyWrapPtr`: Done mainly to follow `PropertyGroup`.
* `NodesModifier`: cannot become purely system idprops currently, as
there is no other access than the 'raw ID properties' paths to their
values. This can be changed once #132129 is finally implemented.
Pull Request: https://projects.blender.org/blender/blender/pulls/135807
This removes the include `UI_interface_layout.hh` from
`UI_interface_c.hh`, and in many places this swaps the include
from `UI_interface.hh` to `UI_interface_layout.hh`.
Also, cleanups some `UI_interface.hh` includes with
`UI_interface_icons.hh` or `UI_interface_types.hh`
Resolve reference counting error in the RNA API which mixed up ownership
between ExtensionRNA::data & StructRNA::py_data.
In practice this generally worked as RNA_struct_free_extension behaved
as if ExtensionRNA owned the reference instead of StructRNA, so as long
as only one reference was removed, there wasn't any difference.
When re-registering Python classes with RNA, ownership wasn't handled
properly which could result in negative reference counts,
crashing in some cases.
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.
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.
Annotation `Callable[[Any, ...], str | None]` is not supported by Python
typing system and ... will be misinterpreted as unknown type instead of
option to provide variable number of arguments.
Ref !138804
