The goal is to make it possible to access evaluated datablocks at a
corresponding context. For example, be able to check evaluated state
if an object used for rendering.
Allows to write scripts in a safe manner for T63548 and T60094.
Reviewers: brecht
Differential Revision: https://developer.blender.org/D5726
Preparing for the bigger changes which will be related on passing
dependency graph to various callbacks which need it.
Differential Revision: https://developer.blender.org/D5725
BF-admins agree to remove header information that isn't useful,
to reduce noise.
- BEGIN/END license blocks
Developers should add non license comments as separate comment blocks.
No need for separator text.
- Contributors
This is often invalid, outdated or misleading
especially when splitting files.
It's more useful to git-blame to find out who has developed the code.
See P901 for script to perform these edits.
Terms get/set don't make much sense when casting values.
Name macros so the conversion is obvious,
use common prefix for easier completion.
- GET_INT_FROM_POINTER -> POINTER_AS_INT
- SET_INT_IN_POINTER -> POINTER_FROM_INT
- GET_UINT_FROM_POINTER -> POINTER_AS_UINT
- SET_UINT_IN_POINTER -> POINTER_FROM_UINT
Folders removed entirely:
* //extern/recastnavigation
* //intern/decklink
* //intern/moto
* //source/blender/editors/space_logic
* //source/blenderplayer
* //source/gameengine
This includes DNA data and any reference to the BGE code in Blender itself.
We are bumping the subversion.
Pending tasks:
* Tile/clamp code in image editor draw code.
* Viewport drawing code (so much of this will go away because of BI removal
that we can wait until then to remove this.
The documentation for the bpy.app.handlers.scene_update_{pre,post}
handlers states that they're called "on updating the scenes data".
However, they're called even when the data hasn't changed. Of course
such handlers are useful, but the documentation should reflect the
current behaviour.
Reviewers: mont29, sergey
Subscribers: Blendify
Maniphest Tasks: T46329
Differential Revision: https://developer.blender.org/D1535
The Issue
=======
For a long time now MinGW has been unsupported and unmaintained and at this point,
it looks like something that we should just leave behind and move on.
Why Remove
==========
One of the big motivations for MinGW back in the day is that it was free compared to MSVC which was licensed based.
However, now that this is no longer true we have basically stopped updating the need CMake files.
Along with the CMake files, there are several patches to the extern libs needed to make this work. For example, see:
https://developer.blender.org/diffusion/B/browse/master/extern/carve/patches/mingw_w64.patch
If we wanted to keep MinGW then we would need to make more custom patches to the external libs and
this is not something our platform maintainers are willing to do.
For example, here is the patches needed to build python: https://github.com/Alexpux/MINGW-packages/tree/master/mingw-w64-python3
Fixes T51301
Differential Revision: https://developer.blender.org/D2648
This is routinely mis-used to continuously run scripts,
causing performance problems.
This should be replaced with more specific handlers, or possibly timers.
See: T47811
Setting all values of a tuple is such a common operation that it deserves its own macro.
Also added Py_INCREF_RET to avoid confusing use of comma operator.
The issue was caused by the changed defaults from the Cycles side.
Because of those properties being saved as an IDProp and not being
saved to the file, every change to the defaults would ruin someone's
day updating the values.
Added a bpy.app.handler.version_update which is run after the regular
do_versions() are done and could be sued by the scripts to apply
versioning code on their settings.
Reviewers: campbellbarton
Reviewed By: campbellbarton
Differential Revision: https://developer.blender.org/D761
this works by tagging functions, eg:
def my_func(scene):
pass
bpy.app.handlers.permanent_tag(my_func, True) # <-- important bit
bpy.app.handlers.frame_change_pre.append(my_func)
