This reverts commit
48abc7aabc &
62599317dd.
Revert !126755 as it was only meant to impact document generation
but it infact made functional changes, see: !135352.
The code-path for coercing a dictionary to operator/gizmo properties
was being used RNA functions where it's not supported.
Raise a type exception instead of crashing.
When called on an object that you cannot get a mesh from (e.g. Empties),
you would run into an unhelpful "SystemError: <built-in method
FromObject of type object at ...> returned NULL without setting an
exception"
Now be more specific in the error message.
Pull Request: https://projects.blender.org/blender/blender/pulls/135162
Add `PointerRNA::reset()` and `PointerRNA::invalidate()` utils functions
(both simply reset the PointerRNA data to empty state).
Replace `RNA_POINTER_INVALIDATE` macro by `PointerRNA::invalidate()`.
Follow-up to !134393 and e55d478c64.
Fixed use of lists using multiple arguments - `list` only
support a single argument.
Noticed working with fake-bpy-module - providing multiple
arguments to `list` resulted in typing error (e.g. "Too many type
arguments provided for "list"; expected 1 but received 2").
Pull Request: https://projects.blender.org/blender/blender/pulls/134663
Reading & restoring RNA "writable" state wasn't working reliably when
Python was called from multiple threads.
- Resolve by acquiring the GIL before calling `pyrna_write_*` functions.
- Assert `pyrna_write_*` has the GIL to prevent this happening again.
- Move duplicate checks from bpy_props.cc into utility functions.
When registering a class, warn if it's base-classes or sub-classes
are already registered as this is bad practice.
Currently the check only runs when the `--debug-python` argument is used
to avoid overhead on startup.
`bpy.utils.unregister_class(bpy.types.Menu)` would remove `bl_rna`
type information from the menu (also Panels & other built-int types).
Prevent unregistering built-in types since this will only cause problems.
Even though from an internal standpoint one could also just use INT
layers (if I understand correctly they are both handled as long?), we
can just support getting/setting bool layers in
the bmesh layer API as well (otherwise, it looks impossible to access
boolean attributes in bmesh).
Pull Request: https://projects.blender.org/blender/blender/pulls/134344
Use `self` parameter to retrieve the actual 'owner' Main.
Previous code was using G_MAIN, which _should_ be fine in current usage
context, but would for sure break if these functions were to be used
from e.g. a temp Main.
Pull Request: https://projects.blender.org/blender/blender/pulls/134440
Cleaner and more future-proof. Also refactored slightly the code to make
it more readable.
And removed the 'experimental' warning in docs, this should have been
removed a long time ago.
Move `Library.runtime` to be a pointer, move the related
`LibraryRuntime` struct to `BKE_library.hh`. Similar to e.g.
Mesh.runtime, that pointer is expected to always be valid, and is
allocated at readtime or when creating a new Library ID.
Related smaller changes:
* Write code now uses standard ID writing codepath for Library IDs too.
* Runtime pointer is reset to nullptr before writing.
* Looking up a library by its absolute path is now handled through a
dedicated utils, `search_filepath_abs`, instead of using
`BLI_findstring`.
Pull Request: https://projects.blender.org/blender/blender/pulls/134188
Currently UI code always has to use char pointers when interacting with
the translation system. This makes benefiting from the use C++ strings
and StringRef more difficult. That means we're leaving some type safety
and performance on the table. This PR adds StringRef overloads to the
translation API functions and removes the few calls to `.c_str()` that
are now unnecessary.
Pull Request: https://projects.blender.org/blender/blender/pulls/133887
The general idea is to store an array of (type, data) pointers of all
PointerRNA ancestors of the current one.
This will help solving cases in our code where the owner (or sometimes
even the owner of the owner) of a random PointerRNA needs to be
accessed. Current solution mainly relies on linear search from the owner
ID, which is sub-optimal at best, and may not even be possible in case a
same data is shared between different owners.
This lead to refactoring quite a bit of existing PointerRNA creation code.
At a high level (i.e. expected usages outside of RNA internals):
* Add `RNA_pointer_create_with_parent` and
`RNA_pointer_create_id_subdata` to create RNA pointers with
ancestors info.
* `RNA_id_pointer_create` and `RNA_main_pointer_create` remain
unchanged, as they should never have ancestors currently.
* Add `RNA_pointer_create_from_ancestor` to re-create a RNA pointer
from the nth ancestor of another PointerRNA.
* Add basic python API to access this new ancestors data.
* Update internal RNA/bpy code to handle ancestors generation in most
common generic cases.
- The most verbose change here is for collection code, as the owner of the
collection property is now passed around, to allow collection items to get
a valid ancestors chain.
Internally:
* `PointerRNA` now has an array of `AncestorPointerRNA` data to store
the ancestors.
* `PointerRNA` now has constructors that take care of setting its data for
most usual cases, including handling of the ancestor array data.
* Pointer type refining has been fully factorized into a small utils,
`rna_pointer_refine`, that is now used from all code doing that operation.
* `rna_pointer_inherit_refine` has been replaced by
`rna_pointer_create_with_ancestors` as the core function taking care of
creating pointers with valid ancestors info.
- Its usage outside of `rna_access` has been essentially reduced to custom
collection lookup callbacks.
Implements #122431.
--------------
Some notes:
* The goal of this commit is _not_ to fully cover all cases creating
PointerRNA that should also store the ancestors' chain info. It only
tackles the most generic code paths (in bpyrna and RNA itself mainly).
The remaining 'missing cases' can be tackle later, as needs be.
* Performances seem to be only marginally affected currently.
* Currently `AncestorPointerRNA` only stores PointerRNA-like data.
This will help `StructPathFunc` callbacks to more efficiently generate
an RNA paths when calling e.g. `RNA_path_from_ID_to_property`, but will
not be enough info to build these paths without these callbacks. And some
cases may still remain fuzzy. We'd have to add thinks like a `PropertyRNA`
pointer, and for RNA collection ones, an index and string identifier, to store
a complete unambiguous 'RNA path' info. This is probably not needed, nor
worth the extra processing and memory footprint, for now.
Pull Request: https://projects.blender.org/blender/blender/pulls/122427
Some versions of PySide give errors when imported together with
bpy.app.translations, because the latter uses a tp_name that does not
exist. The only other tp_name we have with a dot in it (bgl.Buffer)
does exist.
Pull Request: https://projects.blender.org/blender/blender/pulls/134033
Caused by 59dc67974a
The behavior of `RNA_path_from_ID_to_property` /
`RNA_path_from_ID_to_property_index` is that it only gets the "prefix"
of the struct -- the one we are looking for, the one that is missing
here -- if we feed it the `newptr` since it calls
`RNA_path_from_ID_to_struct(ptr)` to get that prefix.
If we feed it the **ID** pointer it will be empty (makes sense it would
basically be "path from ID to ID"...we need it to be "path from ID to
constraint").
Pull Request: https://projects.blender.org/blender/blender/pulls/133977
This makes the code simpler, aligns it with the builtin translations in
messages.cc, and should improve performance as well. My motivation
for the change is to allow returning StringRef/StringRefNull from the
translation functions instead of char pointers.
To test the change I used the Sun Position addon which includes
translations and toggled different languages in the preferences.
Pull Request: https://projects.blender.org/blender/blender/pulls/133827
Previously, the global storage of these types either used a GHash or a
blender::Map. VectorSet is preferrable to GHash because it's type safe,
clearer, and faster. It's preferrable to Map because the key doesn't
have to be duplicated and because iteration is faster.
This PR moves these registered types to VectorSet, just like the
node, node socket, and node tree types. Note that none of these types
use RAII for allocation, so freeing is still done manually.
Testing was manually interacting with each of these systems, including
with addons that register their own types.
Pull Request: https://projects.blender.org/blender/blender/pulls/133778
