There's quite a few libraries that depend on dna_type_offsets.h
but had gotten to it by just adding the folder that contains it to
their includes INC section without declaring a dependency to
bf_dna in the LIB section.
which occasionally lead to the lib building before bf_dna and the
header being missing, while this generally gets fixed in CMake by
adding bf_dna to the LIB section of the lib, however until last
week all libraries in the LIB section were linked as INTERFACE so
adding it in there did not resolve the build issue.
To make things still build, we sprinkled add_dependencies wherever
we needed it to force a build order.
This diff :
Declares public include folders for the bf_dna target so there's
no more fudging the INC section required to get to them.
Removes all dna related paths from the INC section for all
libraries.
Adds an alias target bf:dna to signify it has been updated to
modern cmake
Declares a dependency on bf::dna for all libraries that require it
Removes (almost) all calls to add_dependencies for bf_dna
Future work:
Because of the manual dependency management that was done, there is
now some "clutter" with libs depending on bf_dna that realistically
don't. Example bf_intern_opencolorio itself has no dependency on
bf_dna at all, doesn't need it, doesn't use it. However the
dna include folder had been added to it in the past since bf_blenlib
uses dna headers in some of its public headers and
bf_intern_opencolorio does use those blenlib headers.
Given bf_blenlib now correctly declares the dependency on bf_dna
as public bf_intern_opencolorio will get the dna header directory
automatically from CMake, hence some cleanup could be done for
bf_intern_opencolorio
Because 99% of the changes in this diff have been automated, this diff
does not seek to address these issues as there is no easy way to
determine why a certain dependency is in place. A developer will have
to make a pass a this at some later point in time. As I'd rather not
mix automated and manual labour.
There are a few libraries that could not be automatically processed
(ie bf_blendthumb) that also will need this manual look-over.
Pull Request: https://projects.blender.org/blender/blender/pulls/109835
Originally was noticed when adding drivers to a rigid body., but
it could potentially happen with any configuration.
The reason for the crash was that the ID which was modified was
not tagged as such.
Modifying drivers from the interface are likely tagging for updates
from the operator. This change makes it so the python function also
does tagging.
It is not really how one would design the system nowadays, but it
is how the Blender historically handles such cases. A bigger refactor
is possible to move tags to the places where modification actually
happens, but it seems to be a better idea to tackle it as a separate
project which will be considered no-functional-changes.
Pull Request: https://projects.blender.org/blender/blender/pulls/109895
In edit mode the uv map data length gets set to zero. The specialized
MLoopUV code used to have a check to detect this when trying to access
the UVs using foreach_get/set . Add this check for the Attribute code
path as well.
Pull Request: https://projects.blender.org/blender/blender/pulls/109179
Since d8388ef36a, the "frame_change_post" handler could not be used
anymore to detect when animation playback stopped.
This functionality is needed by certain addons though and is generally
usefull to have, so this is now added.
Related reports : #109168, #109218
Pull Request: https://projects.blender.org/blender/blender/pulls/109232
It was assumed destination buffers were at least 1024 bytes which could
overflow by 256 bytes for sequencer directories. Resolve by passing the
destination buffer size to BKE_bpath_foreach_path_fixed_process.
Also remove strcpy use in foreach_path_clean_cb.
The Python API uses the term size for string lengths for
PyUnicode_AsUTF8AndSize and related API's, causing Blender's return
arguments to use the term `size` too in some cases.
This is error prone since Blender includes space from the the null byte
when the term size is used (by convention).
A lot of files were missing copyright field in the header and
the Blender Foundation contributed to them in a sense of bug
fixing and general maintenance.
This change makes it explicit that those files are at least
partially copyrighted by the Blender Foundation.
Note that this does not make it so the Blender Foundation is
the only holder of the copyright in those files, and developers
who do not have a signed contract with the foundation still
hold the copyright as well.
Another aspect of this change is using SPDX format for the
header. We already used it for the license specification,
and now we state it for the copyright as well, following the
FAQ:
https://reuse.software/faq/
When a file passed in from the command line failed to load,
blender would exit & save the quit.blend.
Resolve by adding a `do_user_exit_actions` to WM_exit_ex which is
false in backgrounds mode or when an error has occurred.
---
Back-ported [0] & [1] from main with fix [2] included.
[0]: c803ddab29
[1]: d7d1c524e3
[2]: d3d91b79e0
When a file passed in from the command line failed to load,
blender would exit & save the quit.blend.
Resolve by adding a `do_user_exit_actions` to WM_exit_ex which is
false in backgrounds mode or when an error has occurred.
This would print whenever 'bpy' was imported, because in this case
Blender's Python integration loads all modules immediately because it
can't import modules as needed via the inittab mechanism.
Also correct code-comments for why inittab can't be used.
Optionally extract all help text, even for options not available
on the current platform or with the current build options.
Useful so it's possible to extract help text for the user-manual
which doesn't depend on the blender build used for extraction.
This hard-coded assumption meant that operators would behave as if
bl_property = "type" was assigned in the operator - when the variable
wasn't found.
Remove the hard coded name. Operators that depended on this now need
to assign bl_property = "type" in the operator class explicitly.
Remove this because it wasn't documented as means operator behavior
could change unexpectedly when renaming a property.
Some property labels need a context to disambiguate them from others
which have the same name.
The only way to show the proper text currently for such properties is
to override it in the UI code with a translation context, like:
```python
layout.prop(obj, "area", text="Area",
context=i18n_contexts.amount)
```
Python properties already store a translation context though, but this
context cannot be chosen from a Python script.
For instance, typing:
```python
bpy.types.Scene.test_area = bpy.props.BoolProperty(name="Area")
print(bpy.context.scene.bl_rna.properties['test_area'].translation_context)
```
will print `*`, the default context for Python props.
This commit allows specifying a context in this manner:
```python
from bpy.app.translations import contexts as i18n_contexts
bpy.types.Scene.test_number_area = bpy.props.BoolProperty(
name="Area", translation_context=i18n_contexts.amount
)
print(bpy.context.scene.bl_rna.properties['test_number_area'].translation_context)
```
will now print `Amount` and can be translated differently from other
labels. In this instance, the word for a surface area measurement,
instead of a UI area.
-----
This is what translated properties look like using the existing ("Area", "") and ("Area", "Amount") messages:
The panel can be generated with this script:
[python_prop_contexts_test.py](/attachments/ab613cdc-8eba-46bc-8f3c-ad0a97e7a6e5)
Pull Request: https://projects.blender.org/blender/blender/pulls/107150
Some property labels need a context to disambiguate them from others
which have the same name.
The only way to show the proper text currently for such properties is
to override it in the UI code with a translation context, like:
```python
layout.prop(obj, "area", text="Area",
context=i18n_contexts.amount)
```
Python properties already store a translation context though, but this
context cannot be chosen from a Python script.
For instance, typing:
```python
bpy.types.Scene.test_area = bpy.props.BoolProperty(name="Area")
print(bpy.context.scene.bl_rna.properties['test_area'].translation_context)
```
will print `*`, the default context for Python props.
This commit allows specifying a context in this manner:
```python
from bpy.app.translations import contexts as i18n_contexts
bpy.types.Scene.test_number_area = bpy.props.BoolProperty(
name="Area", translation_context=i18n_contexts.amount
)
print(bpy.context.scene.bl_rna.properties['test_number_area'].translation_context)
```
will now print `Amount` and can be translated differently from other
labels. In this instance, the word for a surface area measurement,
instead of a UI area.
-----
This is what translated properties look like using the existing ("Area", "") and ("Area", "Amount") messages:
The panel can be generated with this script:
[python_prop_contexts_test.py](/attachments/ab613cdc-8eba-46bc-8f3c-ad0a97e7a6e5)
Pull Request: https://projects.blender.org/blender/blender/pulls/107150
Add a ensure_utf8 argument to WM_clipboard_text_get so callers don't
have to handle validation themselves.
Copying non-utf8 text into the Python console and buttons was possible,
causing invalid cursor position and a UnicodeDecodeError accessing
ConsoleLine.body from Python.
Used to be https://archive.blender.org/developer/D17123.
Internally these are already using the same code path anyways, there's no point in maintaining two distinct nodes.
The obvious approach would be to add Anisotropy controls to the Glossy BSDF node and remove the Anisotropic BSDF node. However, that would break forward compability, since older Blender versions don't know how to handle the Anisotropy input on the Glossy BSDF node.
Therefore, this commit technically removes the Glossy BSDF node, uses versioning to replace them with an Anisotropic BSDF node, and renames that node to "Glossy BSDF".
That way, when you open a new file in an older version, all the nodes show up as Anisotropic BSDF nodes and render correctly.
This is a bit ugly internally since we need to preserve the old `idname` which now no longer matches the UI name, but that's not too bad.
Also removes the "Sharp" distribution option and replaces it with GGX, sets Roughness to zero and disconnects any input to the Roughness socket.
Pull Request: https://projects.blender.org/blender/blender/pulls/104445
- "... (matches pythons ...)": capitalize and use possessive ('s).
- "Layer Proxy Protection": replace proxy by override, following 2.80.
- "Enable Plane Trim": expand description.
- "Make curve path children to rotate along the path": remove "to".
- "Option for curve-deform: make deformed child to stretch along
entire path": remove "to".
- "... apply the curve radius with path following it and deforming":
rephrase unclear description.
- "Custom light falloff curve" : unrelated to lights, used in Grease
Pencil modifiers.
- "Grease Pencil layer assigned to the generated strokes": rephrase
because a GP stroke is assigned to a layer, not the other way
around.
- "Attribute domain where the attribute domain is stored in the
simulation state": remove second "domain" (typo).
Pull Request: https://projects.blender.org/blender/blender/pulls/107916
Only use the term len & maxlen when they represent the length & maximum
length of a string. Instead of the available bytes to use.
Also include the data they're referencing as a suffix, otherwise it's
not always clear what the length is in reference to.
In some cases comments at the end of control statements were wrapped
onto new lines which made it read as if they applied to the next line
instead of the (now) previous line.
Relocate comments to the previous line or in some cases the end of the
line (before the brace) to avoid confusion.
Note that in quite a few cases these blocks didn't read well
even before MultiLine was used as comments after the brace caused
wrapping across multiple lines in a way that didn't follow
formatting used everywhere else.
A recent change from [0] added an assert when a string lookup was
performed on a collection item with no name-property,
but silently failed with release builds.
This isn't correct in a couple of ways.
The assert makes it seem like the RNA API needs to be updated when
it's in fact valid to have collection items without a name-property.
It also misleads script authors to silently fail since it implies a
key that exists would return a result.
Raise a TypeError exception when string lookups are attempted on
collections that don't support them.
This change also applies to get() & __contains__().
[0]: 5bb3a3f157
These two didnt check if keywords were passed in, crashed on running
`PyDict_GET_SIZE` on NULL (in case of no keywords).
Oversight in ee292a1d66.
Now just check if keywords are actually passed in.
Pull Request: https://projects.blender.org/blender/blender/pulls/107285
