Regression in [0] which displays the filename for the active
theme but still used the label internally.
This meant actions such as removing the theme would not always apply
to the name being displayed.
- Adding a new theme was not setting it active.
- Detecting if a theme was built-in used the run-time label as a lookup.
- Theme removal first require it to be re-selected.
[0]: 0bb6317035
This issue occurred only on Mac which has to circumvent
geometry shaders lacking support for them.
This patch reverts the vertex shader for Mac devices to
how it was before f9ea64b0ba. (and uses the frag shader from before that commit)
In order to communicate that to the user I added a label
in the GUI when the platform is Mac.
Co-authored-by: Clément Foucault <foucault.clem@gmail.com>
Pull Request: https://projects.blender.org/blender/blender/pulls/125967
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.
Resolve error when overwriting existing Python modules would attempt
to recursively remove a symlink which raised an error.
Related to #123827, same error but for extensions.
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.
Update `draw_material_settings` to show EEVEE Next properties.
This only changes the internal function, instead of the Panel classes
themselves, to avoid breaking the Python API.
Pull Request: https://projects.blender.org/blender/blender/pulls/125616
A template string was accidentally turned into an f-string in
78b9218c98, which changes the way it is
evaluated. Easy enough to roll back that one change.
Workaround: `[ASN1] nested asn1 error` error when making HTTPS
connections on systems with certificates that OpenSSL cannot parse
are installed.
This is a general issue with Python, resolve by applying a proposed
fix [0] to the extensions Python process at run-time.
(this doesn't impact Blender's Python run-time).
The down side is HTTPS connections will only work for extensions
on systems with this problem so this needs to be resolved by Python
long term.
While any changes to Python's SSL checks is worth avoiding,
this simply skips SSL certificates in the windows store that OpenSSL
can't parse instead of failing all SSL connections.
See related issues:
- https://github.com/python/cpython/issues/79846
- https://github.com/openssl/openssl/issues/25023
[0]: https://github.com/python/cpython/pull/91740
Ref !124943.
Missed after 'Set Snap Base' commit.
Just like in 3D View, UV editing can also benefit from selecting
multiple snap target elements.
The C++ code was already done, it was only necessary to edit the
interface.
Pull Request: https://projects.blender.org/blender/blender/pulls/124986
Since [0] missing repository directories printed a warning on startup.
When checking for blocked extensions on startup, skip directories
that don't exist & don't print any warnings if the repository data
hasn't been downloaded.
[0]: 656fe6d3e4
Support blocking extensions so there is a way for the maintainers of
the remote repository to notify the user if one of their installed
extensions blocked along with a reason for blocking.
Blocked extensions cannot be installed from the preferences or by
dropping a URL.
When an installed & blocked extension is found:
- An icon int the status bar shows an alert,
clicking on the icon shows the blocked extensions.
- The extensions preferences show a warning.
- The extensions & add-ons UI shows an alert icon
and "details" section shows the reason.
Details:
- Blocked & installed extensions are shown first in the installed
extensions panel.
- The internal "install" logic prevents downloading & installing
blocked extensions.
- Blocked extensions can still be downloaded & installed from disk.
- The "list" command includes an error message if any installed
extensions are blocked.
- The "server-generate" command can optionally take a configuration
file that includes the blocklist for the generated JSON.
See design #124954.
Core extensions should have their bugs reported as any other issue in
Blender.
This PR removes their "Rrport a Bug" link.
I left the link only for glTF since it has its own tracker. But I
wouldn't mind removing it as well.
Ref: !125218
When dropping an extension from extensions.blender.org which is
still in the review queue - an error was shown making it seem like
the extension was not compatible with the system.
Adjust wording to clarify that it was not found in the remote repo
which can be caused by it not being part of the repository or when
it's incompatible.
Resolves#125046.
When "bl_info" was on the first line, the legacy add-on would not
install. Correct the check which would also incorrectly detect legacy
add-ons when "bl_info" wasn't found at all.
Regression in [0] caused extensions checks used the same directory & URL
for all remote repositories when checking for updates on startup.
[0]: d2049f0aa7
When the user attempted to install a previously enabled add-on as an
extension after enabling online access and *without* viewing extensions,
installation would fail.
Resolve by adding a check that the remote repository data is available,
adding a button to refresh remote repositories if it's not.
Julien Duroure