Remove a workaround for #23871 which manipulated the module
to prevent classes defined in the text editor from having their
name-space cleared.
This caused the "multiprocessing" module to store the "__main__" module
as "__mp_main__" for later use.
Accessing attributes from this module would then attempt to read from
with a null "mp_dict" which crashed. This happened when showing the
extensions preferences but would have occurred if "__mp_main__" was
accessed from elsewhere too.
Resolve by removing the workaround since it has not been needed
since Python 3.2.
- `_PySet_NextEntry` has been removed, use generic iterator access
which will has some additional overhead as it needs to create
an iterator to access the values.
- Add v3.13 compatibility defines to account for renaming:
_PyObject_LookupAttr -> PyObject_GetOptionalAttr
_PyLong_AsInt -> PyLong_AsInt
- Unfortunately use of Python's internal API needs to be used to
inspect op-codes in `bpy_driver.cc`.
Testing GLTF/FBX IO there isn't any significant performance impact
from these changes.
Resolves#123871.
Essentially, our current code would not properly remove (dereference)
its python objects matching various RNA data created during execution.
Some cases are fairly trivial to understand (like the lack of handling
of unregstering for our 'startup' operators and UI), other were more
subtle (like unregistered PropertyGroups who would remove/free their RNA
struct definition, without releasing first the potential matching python
object).
Co-authored-by: Campbell Barton <campbell@blender.org>
Pull Request: https://projects.blender.org/blender/blender/pulls/128899
Move most of the string preprocessing used for MSL
compatibility to `glsl_preprocess`.
Enforce some changes like matrix constructor and
array constructor to the GLSL codebase. This is
for C++ compatibility.
Additionally reduce the amount of code duplication
inside the compatibility code.
Pull Request: https://projects.blender.org/blender/blender/pulls/128634
The `pre` handler is called after blender internal code is done populating
the link/append context with data to be processed, and before this data
starts being linked from library files.
The `post` handler is called after blender is done linking, and
potentailly appending and/or instantiating, the requested data and all
of their dependencies.
Both handlers are called with a single argument, the link/append
context.
An new RNA sets of wrappers have been added to expose relevant info from
these internal C++ structures.
NOTE: !113658 is very similar (but tied to asset drag & drop), whereas
this PR is more general (these could probably live hand-in-hand / side-
by-side).
Implements #122357
Pull Request: https://projects.blender.org/blender/blender/pulls/128279
-----------------
Some quick py example code:
```python
import bpy
def my_handler_pre(lapp_context):
print("About to {}:\n\t".format("link" if "LINK" in lapp_context.options else "append"),
"\n\t".join("{} '{}', from libs ['{}']".format(item.id_type, item.name,
"', '".join([l.filepath for l in item.source_libraries]))
for item in lapp_context.import_items))
def my_handler_post(lapp_context):
print("{}:\n\t".format("Linked" if "LINK" in lapp_context.options else "Appended"),
"\n\t".join("{} '{}', from lib '{}'".format(item.id.id_type, item.id.name, item.source_library.filepath)
for item in lapp_context.import_items))
bpy.app.handlers.link_append_pre.append(my_handler_pre)
bpy.app.handlers.link_append_post.append(my_handler_post)
```
This replaces the older dynamic c array macros with blender::Vector in
bmesh_polygon_edgenet. This is the only remaining use of the old array
machinery and removal of `BLI_array.h / .c` can happen immediately
afterwards.
See #103343
Pull Request: https://projects.blender.org/blender/blender/pulls/119975
Documentation of the `gpu.state.active_framebuffer_get` is inconsistent.
It mentions `framebuffer_active_get`. I believe the cause is that the
C methods in the Python wrapper are named inconsistently.
This PR fixes this by making the wrapper + documentation consistent
with the top level API.
Pull Request: https://projects.blender.org/blender/blender/pulls/127677
Disable dynamic SDL loading as well as disable SDL for release builds.
This was only used for audio output which can already use OpenAL
if there are back-ends not natively supported by Blender.
- Remove extern/sdlew/
- Remove the WITH_SDL_DYNLOAD build option.
- Remove `bpy.app.sdl.available`.
Ref !127554
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>
This is just not supported, and typically not doable from Blender UI
(since embedded IDs won't be listed in ID template list).
Add asserts to IDProp code itself, and checks & error reports in
relevant BPY and RNA setters.
