The issue was that the Python keyframing code was already resolving the
RNA path fully to the owning ID, but then erroneously passing the
non-ID RNA pointer (in this case the sound sequence pointer) to the
keyframing code with that fully resolved path.
Notably, it wasn't just the VSE keyframing that was broken: keying any
non-ID structs via the Python API was broken. A good example is pose
bones: the Python keyframing code was resolving e.g. "location" on
the bone to "pose.bones["Bone"].location", but then passing that
path along with the pose bone struct to the keyframing code. Since
that fully resolved path of course doesn't exist on the bone itself,
keying would fail.
This fixes it by simply passing the owning ID's RNA pointer instead,
which it should have been doing in the first place.
Pull Request: https://projects.blender.org/blender/blender/pulls/123719
Reference identifiers instead of "above" in code comments as these
tends to become outdated. Even when declarations are removed it's at
least clear that the reference no longer exists instead of referring to
whatever is currently above the declaration.
It's also straightforward to search history for a removed identifier.
Corrected 4 cases of references to things that were no longer above
the doc-strings. Noticed other references which look to be incorrect
but need further investigation.
Add-ons may attempt to load the GPU module in background mode when no GPU
context has been initialized yet. This would give an error on import.
If then later the GPU context does get initialized, for example for a
render engine, import would still fail as the module is cached.
This reverts commit d7f124f06f, and again
throws errors in methods and constructors instead of module import.
Pull Request: https://projects.blender.org/blender/blender/pulls/123395
Add a `.data<T>()` method that retrieves a mutable span. This is useful
more and more as we change to filling in vertex buffer data arrays
directly, and compared to raw pointers it's safer too because of asserts
in debug builds.
Pull Request: https://projects.blender.org/blender/blender/pulls/123338
The current temperature unit adjusts to Celsius or Fahrenheit based on
unit system, but specifically for color temperatures the convention is
to display them in Kelvin, and it'd be strange to e.g. see 11240°F when
opening the white balance panel.
Therefore, this adds a dedicated Color Temperature unit, and uses it
for the two existing blackbody temperature inputs in shader nodes.
Pull Request: https://projects.blender.org/blender/blender/pulls/123337
Allow assigning integer values beyond int32 range to float/double
IDProperties. Extract the py object value into a temporary int64 value
in these cases.
This implements (most of) the proposal in #122743:
* Add a new `IDP_FLAG_STATIC_TYPE` IDProperty flag.
* Update `BPy_IDProperty_Map_ValidateAndCreate` and related to never
change an existing property type if statically typed.
The biggest change happens in bpy assignement code, since instead of
replacing the old exisitng property by a newly created one, and copying
over a few settings, now the old property is kept if possible, and a new
one is only created if needed.
And in case the existing property is statically typed, if it cannot be
re-used to store the given value, and error is reported and it remains
unchanged.
`IDP_ARRAY` is also supported for basic numeric types, so 'vector'
properties and such work as expected. Lentgh is considered as part of
the static type (i.e. one can only assign a 3 components py sequence to
a 3-len array property, etc.).
Such in-place update is not yet implemented for `IDP_IDPARRAY` and
`IDP_GROUP` types. While important (especially the group one), they are
not that critical for the current issues related to changing IDProperty
types.
7413031dd6 introduced an error and related warning when generating Py API docs:
```
/blender/doc/python_api/sphinx-in/bpy.app.translations.rst:132: ERROR: Unexpected indentation.
...
/blender/doc/python_api/sphinx-in/bpy.app.translations.rst:132: WARNING: Lexing literal_block 'See :func:`pgettext` notes.' as "python3" resulted in an error at token: '`'. Retrying in relaxed mode.
```
Pull Request: https://projects.blender.org/blender/blender/pulls/123097
The goal of this PR is to merge `insert_keyframe()` and `insert_key_rna()` into
a single function, `insert_keyframes()`, that fully accommodates the
functionality of both. This results in a bit of a mega function, which isn't
great, but it centralizes a lot of otherwise redundant keyframing code so it
only needs to be changed in one place in the future.
Future PRs can work to reduce the "mega" aspect of this function, stripping it
down to its core functionality and eliminating left over incidental redundancy
(e.g. passing both `scene_frame` and `anim_eval_context`).
As a wonderful side effect, this PR also makes layered action keyframing work in
most of the remaining places left over from #121661, such as buttons, the
dopesheet, the graph editor, etc.
Pull Request: https://projects.blender.org/blender/blender/pulls/122053
The new `pgettext_n` function (typically imported as `n_`) can be used
when there is a need to extract messages, without translating them. It
is essentially a no-op equivalent to the C++ version `N_`.
Just for the `pyrna_struct_keyframe_insert()` function, reduce the
reporting level of keyframe insertion failures from `RPT_ERROR` to
`RPT_WARNING`. This prevents the conversion of these reports to a Python
exception.
`CombinedKeyingResult::generate_reports()` now accepts an option
argument `report_level`, so that the caller is in control over the type
of reports it generates.
Previously only errors were converted to exceptions; warnings were
implicitly cleared and never displayed. To avoid these 'keyframe
insertion failure' reports from becoming invisible, the
`pyrna_struct_keyframe_insert()` function now sends any warnings to
stdout (unless there were errors, in which case the old
error-to-exception behaviour is still there).
Pull Request: https://projects.blender.org/blender/blender/pulls/122827
`BMVert.copy_from_vert_interp()`'s description and the name `vert_pair`
implies two verts, but the argument itself was described and typed as a
single `BMVert`.
Ref: !122974
Mainly correct/update some comments (e.g. missing reference to Boolean
type), and add some notes essentially about issues with current IDProp
String code (see also #86960 ).
No functional change.
The buttons to upgrade or sync extensions called extension
operators via bpy.app.handlers, requiring awkward glue-code
which didn't show error reports in to the user.
Remove these operators and call the upgrade & sync operators directly.
Support for "System" extensions as an alternative to the current
"User" extensions repository.
The purpose of this change is to support bundling extensions for
offline work or in environments where users setting up thier own
extensions isn't desirable, see #122512.
Details:
The default "System" repository on Linux will for example use:
- `/usr/share/blender/4.2/extensions/{system}` For system installs.
- `./4.2/extensions/{system}` For portable installs.
- Blender's default startup now has a "System" repository
which users or administrators may populate.
- Repositories can select between User/System paths,
setting a custom path overrides overrides this setting.
- Add "BLENDER_SYSTEM_EXTENSIONS" (matching "BLENDER_LOCAL_EXTENSIONS").
Ref !122832
The type for `bpy_struct.keyframe_insert()`'s `options` parameter was
instead applied to a non-existent `flag` parameter.
The description and type for `mathutils.Vector.Repeat()`'s `vector`
parameter was instead applied to a non-existent `tuple` parameter.
Also fix a reference to `BMElemeSeq` instead of `BMElemSeq`.
Ref: !122734
- Support passing in operator ID's using Python dot syntax.
- Support define operators that haven't yet been registered
matching Blender's own behavior.
Also add doc-string for bpy.types.Macro.define.
- `BMLayerItem.copy_from(other)` had a typo in its docstring that prevented `other` being typed.
- `BMesh.from_object()` and `BMesh.from_mesh()` had untyped arguments.
- `BMVert.copy_from_vert_interp()`'s `fac` argument was untyped.
- `remove(item)` method of `BMVertSeq`, `BMEdgeSeq` and `BMFaceSeq` had no type for `item`.
- `get()` method of `BMEdgeSeq` and `BMFaceSeq` had "sequence" in the description of `verts` but not in the type.
Pull Request: https://projects.blender.org/blender/blender/pulls/122374
The "render_stats" handler now includes the message line that was
written to stdout as the first arg (using `BKE_callback_exec_string`
instead of just `BKE_callback_exec_null`).
This can be useful to track render progress (and people were relying on
parsing stdout in the past).
Was a request in chat.
This also corrects possible output from the callback being written in
between message parts in `do_write_image_or_movie` (which was probably a
mistake in 93d5e106aa).
Pull Request: https://projects.blender.org/blender/blender/pulls/119789
Sometimes it is necessary to pass additional data through generic UI entities,
to specific implementations. For example to pass additional options to panel
polling & drawing when instantiating a panel through its panel type. Or storing
additional data in a button, without hardcoding it in the button struct/class.
Passing data via context is a simple solution to this, however so far this only
works using hardcoded context queries or RNA pointers. For passing arbitrary
strings we've used workarounds like creating an RNA type to wrap it already.
For example `RNA_AssetCatalogPath`, which is used to dynamically populate menu
items based on an asset catalog path, via a generic menu type.
type instantiation. This makes it possible to invoke specific asset shelves as
popover panels.
Idea is simply to let `bContextStore` entries hold copies of the string (as
`std::string`), avoiding lifetime issues. Context APIs are extended to support
setting/querying strings via a context member name.
Pull Request: https://projects.blender.org/blender/blender/pulls/122113
It would crash with no `id_type` specified.
Custom Properties Datablock Pointers were introduced in the UI in
b3c7f3c8a9.
When created via python, we dont enforce a `id_type`, when done via the
UI, this should be set though. However, I think when using `update()`,
the `id_type` is optional, so should be possible to just change the
`description` for example and leave the type untouched.
Code was trying to get the id type from the string passed in (None in
this case) and crashed somewhere along the way of
`pyrna_enum_value_from_id` which such NULL string.
So to resolve, just leave the `id_type` untouched if nothing is
specified here.
Pull Request: https://projects.blender.org/blender/blender/pulls/122306
Splash screen notification text:
- When starting in "Offline mode" with repositories with installed
packages enabled, the text is clickable unless launched with
`--offline-mode`, the tooltip notes that the command line setting
can't be changed at run-time.
- Don's show anything if there are not extensions installed.
Preferences:
- Don't show the welcome message on preferences if:
- Blender is online.
- The message was dismissed.
- There are no enabled remote repositories.
- The option to enable extensions.blender.org has been replaced with
a button that switches to the "System" tab where Online Access
can be enabled.
Also expose bpy.app.online_access_override needed for the UI to check
if online access was disabled using command line arguments.
Add a preference to "Work Offline" system preference as well as command
line options `--offline-mode` & `--online-mode`
(which overrides the preference).
This option is displayed in the initial setup screen too.
This is currently respected by:
- Check for updates on startup
- Disables running an update when enabling extensions.
When Blender is launched with `--offline-mode` the option cannot be
enabled in the preferences. This is intended for environments
where internet access is intentionally disallowed.
Background: with Blender supporting access to online-repositories
as well as 3rd party extensions themselves potentially accessing the
internet. This setting provides a way for users to disable online
functionality.
This prevents error messages when online access fails in environments
without internet access as well as the ability for users who prefer
Blender doesn't access the internet to have one place to turn this off.
While it does not enforce limitations on add-ons, 3rd party scripts
are expected to respect this setting using `bpy.app.internet_offline`.
The details for this will be handled along with other policies scripts
are expected to follow.
Ref !121994
Move all header file into namespace.
Unnecessary namespaces was removed from implementations file.
Part of forward declarations in header was moved in the top part
of file just to do not have a lot of separate namespaces.
Pull Request: https://projects.blender.org/blender/blender/pulls/121637
Overlay texts were previously drawn with two sets of shadows:
- 3px blur,
- 5px blur, slightly offset
But since the shadow color was always set to black, it was still
causing legibility issues when the text itself was dark (set
via theme for example).
This PR adds a new "outline" BLF text decoration, and uses that
for the overlays. And it picks text/outline color depending
on the "background" color of the view.
Details:
- Instead of "shadow level" integer where the only valid options
are 0, 3 or 5, have a FontShadowType enum.
- Add a new FontShadowType::Outline enum entry, that does a 1px
outline by doing a 3x3 dilation in the font shader.
- BLF_draw_default_shadowed is changed to do outline, instead of
drawing the shadow twice.
- In the font shader, instead of encoding shadow type in signs of
the glyph_size, pass that as a "flags" vertex attribute. Put
font texture channel count into the same flags, so that the
vertex size stays the same.
- Well actually, vertex size becomes smaller by 4 bytes, since turns
out glyph_mode vertex attribute was not used for anything at all.
Images in the PR.
Co-authored-by: Harley Acheson <harley.acheson@gmail.com>
Pull Request: https://projects.blender.org/blender/blender/pulls/121383
Handling of the blendfile handle freeing when linking data from a
blendfile requiring endianness conversion was totally broken, leading
to double-freeing attempts.
Guess that the fact that this was never reported shows how rare
'big-endian' blendfiles are nowadays... But we still have a few in our
test repo.
