Use common prefix as this collided with existing API's (eg BLI_voronoi).
Also expand some non-obvious abbreviations:
- 'g' -> 'generic'
- 'vl' -> 'variable_lacunarity'
- 'V' -> 'v3'
Fixes 18 misspellings of 'predefined', 'Look Up', 'Lookup', and 'No One'.
Differential Revision: https://developer.blender.org/D9466
Reviewed by Hans Goudey
This was added when Python was initially bundled so any problems
finding Python could be investigated.
Move this to use logging so we can show this information when needed.
This reverts commit 6527a14cd2.
Some 3rd party scripts made use of this so scripts can work with
2.90 to 2.92, although eventually this can still be removed.
Some subtypes never made it to all neccessary places when they were
introduced. This was throwing warnings when accessing such a properties
subtype from python.
The sub_type enums were also defined in 4 different places:
- RNA_types.h 'PropertySubType'
- rna_rna.c 'rna_enum_property_subtype_items'
- rna_rna.c 'subtype_items'
- bpy_props.c as multiple enums
This patch syncs the definitions across all places so that they are the
same everywhere. It also looks redundant to define these twice in
rna_rna.c, now just use 'rna_enum_property_subtype_items' there (and get
rid off 'subtype_items').
Also moved 'POWER' & 'TEMPERATURE' to number enum in bpy_props (these
were defined in the array enum).
Fixes T82167.
Maniphest Tasks: T82167
Differential Revision: https://developer.blender.org/D9371
`sys.executable` is documented to be a Python interpreter or None.
This was set to Blender's executable which caused the multiprocessing
module to spawn new instances of Blender instead of Python on WIN32.
See issue described in D7815.
Deprecate 'bpy.app.binary_path_python' & warn when using.
Blender's executable remains accessible via `bpy.app.binary_path`.
Modified 04c5471cee, setting `sys.executable` instead of using
Py_SetProgramName, which is needed for a bundled Python installation.
`sys.executable` is documented to be a Python interpreter or None.
This was set to Blender's executable which caused the multiprocessing
module to spawn new instances of Blender instead of Python on WIN32.
See issue described in D7815.
Deprecate 'bpy.app.binary_path_python' & warn when using.
Blender's executable remains accessible via `bpy.app.binary_path`.
Corrects incorrect usages of the word 'loose' when 'lose' was required.
Differential Revision: https://developer.blender.org/D9243
Reviewed by Campbell Barton
Corrects incorrect usage of contraction for 'it is', when possessive 'its' was required.
Differential Revision: https://developer.blender.org/D9250
Reviewed by Campbell Barton
Calling PyEval_ReleaseLock() was crashing with Python 3.9
because it accessed the NULL pointer set by PyThreadState_Swap().
This happened when calling ViewLayer.update() for example.
While the existing logic could be fixed by swapping the thread-state
back before calling PyEval_ReleaseLock(), this depends on functions
which are tagged to be removed by v4.0.
Replace use of deprecated functions by calling PyEval_SaveThread(),
instead of inlining the logic, using _PyThreadState_UncheckedGet()
to prevent Python aborting.
The call to PyEval_ThreadsInitialized has been removed
as threads are now initialized with Python.
This could be replaced with Py_IsInitialized() however it doesn't look
like this is necessary.
This is compatible with Python 3.7 & 3.9.
- BKE_bezt_subdivide_handles -> BKE_fcurve_bezt_subdivide_handles
- binarysearch_bezt_index -> BKE_fcurve_bezt_binarysearch_index
These functions are specific to F-Curves and don't make sense for other
uses of BezTriple (curve-object data for e.g.)
Also:
- Move detailed doxygen comment above code, following code-style.
- Mark bezt_add_to_cfra_elem unused.
This directly adress the issues caused by rB536c2e0ec916.
Since the state tracking is done at a lower level, using the bgl
functions needs to be safegarded by the state manager.
The current workaround is to bypass `apply_state` when inside a
callback that used a `bgl` function.
Related to T80730.
This fix T81003.
Also this fix the default blend equation for callbacks.
Fixes T80169 T81289.
We have our own assert implementation, `BLI_assert()` that is prefered over the
C standard library one. Its output is more consistent across compilers and
makes termination on assert failure optional (through `WITH_ASSERT_ABORT`).
In many places we'd include the C library header without ever accessing it.
Define enum `eContextResult` and use its values for returns, instead of
just returning 1, 0, or -1 (and always having some comment that explains
what -1 means).
This also cleans up the mixup between returning `0` and `false`, and `1`
and `true`. An inconsistency was discovered during this cleanup, and
marked with `TODO(sybren)`. It's not fixed here, as it would consititute
a functional change.
The enum isn't used everywhere, as enums in C and C++ can have different
storage sizes. To prevent issues, callback functions are still declared
as returning`int`. To at least make things easier to understand for
humans, I marked those with `int /*eContextResult*/`.
This is a followup of D9090, and is intended to unify how context
callbacks return values. This will make it easier to extend the approach
in D9090 to those functions.
No functional changes.
Differential Revision: https://developer.blender.org/D9095
