The issue was that the API assumed that the `.selection` attribute
was always on either the point domain for points or the stroke domain
for strokes.
Internally the attribute domain depends on the current selection mode.
To fix the issue, the API now checks for the domain of the attribute
and handles it accordingly.
If the selection attribute is on the `'POINT'` domain:
* Reading the `stroke.select` property will check if *any* of the points of
the stroke are selected and return `True` or `False`.
* Writing to the `stroke.select` property will write `True` or `False` to *all* the
points in the stroke.
Also resolves#128645.
Pull Request: https://projects.blender.org/blender/blender/pulls/128687
This should free up references to GPv2 types and operators and should
in turn make their removal easier.
- Remove keymaps for GPv2 operators from `blender_default.py` and
`industry_compatible_data.py`
- Remove keymap poll callback assignment from `gpencil_ops.cc`
- Remove keymap handler registration from `area.cc:ed_default_handlers`
Pull Request: https://projects.blender.org/blender/blender/pulls/128480
On Windows an entire directory may be locked when any files inside it
are opened by another process. This can cause operations that
recursively remove a directory (uninstalling & updating) to fail
with a partially removed extension.
The case of uninstalling was already handled, where failure to remove
a directory would stage the extension for later removal.
In the case of updating however, the user could be left with a broken
(partially removed) extension where some files were removed, as the
directory was locked, the update would fail to extract new files.
Address this issue by renaming the directory before recursive removal.
The following logic has been implemented:
- If any files in the directory are locked, renaming will fail.
So even though the operation fails the extension is left intact.
- If renaming succeeds, it's possible to apply the update.
While it's possible (albeit unlikely) recursive removal fails,
which could be caused by file-system permissions issues corruption or
a process could open a file between rename & removal.
In this case the renamed directory is staged for later removal.
Other changes:
- Resolve a related problem where the user could install an
extension previously staged for removal, now installing an extension
ensured it's not removed later.
This would occur if uninstalling failed, the user resolves
directory-lock, uninstalls again, then re-installs the extension.
- When an extension fails to be removed, don't attempt to remove
user configuration for that extension.
Prefer to keep the extension & it's settings in their "current state"
if it can't be removed.
BaseException was used as a catch-all in situations where it
didn't make sense and where "Exception" is more appropriate
based on Python's documentation & error checking tools,
`pylint` warns `broad-exception-caught` for e.g.
BaseException includes SystemExit, KeyboardInterrupt & GeneratorExit,
so unless the intention is to catch calls to `sys.exit(..)`,
breaking a out of a loop using Ctrl-C or generator-exit,
then it shouldn't be used.
Even then, it's preferable to catch those exceptions explicitly.
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.
- Move sys_info into an internal module to avoid having so many
top level modules for Blender's internal functionality.
- Rename system_info sub-modules that pre-fill URL's for clarity.
- Move top-level exception handling into the operator.
- Report an error if an unexpected exception occurs.
- Use `Exception` instead of `BaseException` as there is no reason to
catch the additional exceptions.
- Remove use of sys_info from the command line example,
replace with in-lined system info.
This commit adds a python script that can collect some of the
information necessary to fill out a bug report.
The primary use case is to help users collect system information for
a bug report in the case that Blender can't open.
CMD and sh files are included to help users use the Python script.
Ref !122191
Recent fix 21b820cd33 in BPY/RNA code broke introspection code of RNA
data in i18n message extraction code.
Luckily, it actually fixes things, and allows to remove some of the ugly
hacks we had in this code, especially regarding Operators handling.
When point/curves count of a `GreasePencilDrawing` is changed, prior stroke
slices are no longer valid. This is not obvious when using the `stroke()`
call since it is meant to provide a easier access to the drawing data and
did not represent the actual data layout in the drawing, hence we need an
additional note in the document to tell users to be more careful.
Pull Request: https://projects.blender.org/blender/blender/pulls/126815
Writing to the `curve_type` attribute directly is not allowed as there are other
updates needed and otherwise will result in a crash.
The fix makes sure the `curve_type` is read-only. To change the curve type,
the `grease_pencil.set_curve_type` operator has to be used for now.
With layered actions, the bake action wasn't working.
More specifically it failed to create a slot on the action
and link that slot on the animation data.
The fix is to create the slot.
Pull Request: https://projects.blender.org/blender/blender/pulls/126546
This moves the helper python classes from `scripts/modules/grease_pencil_python.py`
to `scripts/modules/_bpy_internal/grease_pencil.py`.
It also cleans up the code a bit more. No functional changes.
Pull Request: https://projects.blender.org/blender/blender/pulls/126403
This extends the `GreasePencilDrawing` rna type using python.
The goal is to add an API that allows developers to transition to
the new grease pencil API a bit more smoothly.
Adds the following endpoints to the `GreasePencilDrawing`:
* `drawing.strokes`: Returns a list/slice of `GreasePencilStroke`s in the drawing.
Adds a python class `GreasePencilStroke`:
* `stroke.points`: Returns a list/slice of `GreasePencilStrokePoint`s.
* Getters/Setters of attributes for this stroke:
* `stroke.cyclic`
* `stroke.material_index`
* `stroke.select`
* `stroke.softness` (used to be `hardness`)
* `stroke.start_cap`
* `stroke.end_cap`
* `stroke.curve_type`: The type of curve: `POLY`,`BEZIER`,`CATMULL_ROM`,`NURBS`.
* `stroke.aspect_ratio`
* `stroke.fill_opacity`
* `stroke.fill_color`
* `stroke.time_start`
* High-level functions:
* `stroke.add_points(count)`: Adds `count` points at the end of the stroke.
* `stroke.remove_points(count)`: Removes `count` points from the end of the stroke. Note that this will not remove the stroke if the count is greater than the number of points in the stroke. A stroke has at least 1 point. Removing strokes can be done from the drawing.
Adds a python class `GreasePencilStrokePoint`:
* Getters/Setters of attributes for this point:
* `position`
* `radius`
* `opacity`
* `select`
* `vertex_color`
* `rotation`
* `delta_time`
Note that `GreasePencilStroke` and `GreasePencilStrokePoint` are not stored in the file and don't have an RNA API. This means that they are not compatible with e.g. `layout.prop`.
This API should not be used for performance critical code. It's likely
even slower than the python API from 4.2.
There will be migration documentation for addon developers here:
https://developer.blender.org/docs/release_notes/4.3/grease_pencil/#python-api-changes
Pull Request: https://projects.blender.org/blender/blender/pulls/125599
The lazy-connect feature of node wrangler uses the built-in `connect_sockets`
function which automatically handles virtual sockets in group input and output
nodes already. However, it does not handle virtual sockets in other nodes.
The fix is to generalize this behavior. For that, a new `handle_dynamic_sockets`
boolean input is added to `tree.links.new`. When enabled, virtual sockets are
handled properly by internally calling the `bNodeType.insert_link` methods.
The new behavior is turned of by default for compatibility reasons.
Pull Request: https://projects.blender.org/blender/blender/pulls/126282
- Paths of C++-parsed files were not properly 'unixified' on Windows.
This was bad both for changes noisyness in PO files, and broke on
the un-escaping of `\n` and `\t` sequences.
- The `ProcessPoolExecutor` starts sub-processes differently on Linux
than on Windows or OSX. While Linux's `fork` keeps the same
environment (i.e. all Blender stuff remains available in workers
subprocesses), the 'spawn' used on Windows (and reportedly OSX) starts
a new bare python interpreter. This means that code executed by these
needs to be Blender-agnostic to be portable.
The only thing that is currently known broken on non-Linux platforms is
the RTL processing of some languages like Arabic or Hebrew.
When deleting files on WIN32, open files cannot be removed.
This is especially a problem for compiled Python modules which
remain open once imported.
Previously it was not as common for add-ons to include compiled Python
modules however with extensions supporting Python-wheels,
it's increasingly likely users run into this.
Workaround the problem by:
- Scheduling the files for removal next time Blender starts.
- Rename paths that cannot be removed to avoid collisions when
the paths is reused (re-installing for example).
This is supported for:
- Extensions.
- Python wheels.
- Legacy user add-ons.
- App-templates.
Details:
- On startup, a file exists that indicates cleanup is needed.
In the common case the file doesn't exist.
Otherwise module paths are scanned for files to remove.
- Since errors resolving paths to remove could result in user data loss,
ensure the paths are always within the (extension/addon/app-template)
directory.
- File locking isn't used, if multiple Blender instances start at the
same time and try to remove the same files, this won't cause errors.
Even so, remove the checking file immediately avoid unnecessary
file-system access overhead for other Blender instances.
Also resolves#125049.
Expose arguments to use when creating a Python sub-process.
Python could fail to start when loaded in a customized environment,
with PYTHONPATH set for e.g. Blender ignores these and loads but a
Python sub-process attempts to use these environment variables which
may point to incompatible Python versions.
Resolve the root cause of #124731.
