Provide a convenient way to access a writable directory for extensions.
This will typically be accessed via:
bpy.utils.extension_path_user(__package__, create=True)
This API is provided as some extensions on extensions.blender.org
are writing into the extensions own directory which is error prone:
- The extensions own directory is removed when upgrading.
- Users may not have write access to the extensions directory,
especially with "System" repositories which may be on shared network
drives for example.
These directories are only removed when:
- Uninstalling the extension.
- Removing the repository and its files.
The new extension system introduces tags, similar to categories from
legacy add-ons, and permissions. A hardcoded list is supported for
each, available in the docs:
- https://docs.blender.org/manual/en/dev/advanced/extensions/tags.html
- https://developer.blender.org/docs/features/extensions/schema/
This change allows extraction of these new metadata to the translation
files.
In order to disambiguate the new messages, tags use the new "Script"
translation context. Permissions are lower case, so there is a low
risk of collision, and they use the default context.
While the tags are defined per-platform, with extensions.blender.org
being the only one available currently, they are extracted as a single
list.
Pull Request: https://projects.blender.org/blender/blender/pulls/123150
The issue was that when applying the keyingsets
`Whole Character` and `LocRotScale & Custom Properties` the
enum property of a rigify rig was not keyed.
The reason it was not keyed was just because
it was not specified in the compatible types in the keying set.
The fix is to just add `bpy.types.EnumProperty` to the list.
Pull Request: https://projects.blender.org/blender/blender/pulls/122377
* Drop the repository - let's combine tags in a single list (per type)
to avoid duplications in the future.
* Give a more sensitive name for tthe property, to avoid tags.tags.
This patch removes the Auto Render option from the compositor. This is
done for the following reason:
- The option didn't really work except in the case of transforming an
object. So it wasn't really reliable.
- It made little sense to use since the introduction of the Viewport
Compositor.
- It had a number of UX issues, including the fact that it can't be used
with animation playback, and the fact that rendering can get in the
way of the UI depending on the preferences for temporary editors.
Pull Request: https://projects.blender.org/blender/blender/pulls/123132
- The "location" and "warning" fields in bl_info are no longer exposed
in the interface, so there is no need to extract them any more.
- Some add-ons do not define a description (Copy Global Transform for
example), so they should be skipped.
- Some third-party legacy add-ons do not use the 'support' field, and
that can cause an error in extraction. Since this won't happen
for built-in add-ons, checking that an add-on is built-in is enough.
Pull Request: https://projects.blender.org/blender/blender/pulls/122970
All add-ons were being scanned at startup, while this didn't cause
errors it was noticeable with extensions where any errors in the
manifest were being reported at startup, even when running with
factory-startup (including blender's own tests).
Address two issues:
- The logic to "reset" add-ons, so as to match the preferences when
reverting or resetting preferences always ran on startup.
This occurred because a check for Python being initialized was
incorrectly used to detect that this wasn't the first time preferences
were being loaded (regression in [0]).
- Resetting add-ons scanned all add-ons (including disabled add-ons) to
ensure their module cache is up to date. Since this the cache is
lazily initialized, it's simpler to set it as uninitialized as
resetting the add-ons doesn't require the cached meta-data.
[0]: 497bc4d19977abc7b9e2c0f5024a23057e680954
autopep8_format_paths.py was never wired up in the windows tooling,
this PR wires it up, to get around a 8191 limitation for command
lines on windows an alternative "--no-subprocess" option has been
introduced to call the pep8 module directly from python.
TODO: A subprocess is still used for getting the version information
Contributors:
- @campbellbarton fixes to autopep8_format_paths.py to support
the -no-subprocess option.
Pull Request: https://projects.blender.org/blender/blender/pulls/120794
Originally this would replace scripts that come bundled with Blender,
but it's unclear how this is useful.
Searching for this online mainly leads to people asking how they can
use it to add scripts. For example in a studio environment you might
want to deploy add-ons and startup scripts for all users.
Even if you wanted to use it for replacement though, it wasn't really
doing that and inconsistent for different types of scripts:
* startup: ignored
* modules: replaces bundled scripts
* presets: adds to bundled scripts
* addons (in 4.1): ignored
* addons_core (in 4.2): ignored
* startup/bl_app_templates_system: replaces bundled scripts
This change makes it add scripts from this path for all. This is a
breaking change, though arguably this feature was just broken to
begin with and not used much in practice because of that.
The alternative would be add a new set of environment variables to
avoid breaking existing behavior. But that also means keeping around the
broken behavior or fixing it in another way.
Supporting multiple paths may be used too, but for now just support
a single one as doing this for all BLENDER_SYSTEM variables is
non-trivial. The main use case for that would be add-ons anyway, and
those will mainly be handled through upcoming
BLENDER_SYSTEM_EXTENSIONS instead.
Ref #122512
Pull Request: https://projects.blender.org/blender/blender/pulls/122689
The translation extraction goes through each keyconfig preset file and
activates it in order to extract its messages. This change makes it
restore the original config, otherwise it would end up switching to
Industry Compatible.
Pull Request: https://projects.blender.org/blender/blender/pulls/122789
The "active_file" context member as a way to get the active asset should be
avoided, in favor of "asset". This moves us away from the file browser backend
as basis of the asset system,
Using `bpy.types.OperatorProperties.__subclasses__()` has become utterly
unreliable now, to the point that it keeps references to freed (aka
unregistered) operators now, leading to crash when accessing them.
This commit refactors quite seriously the `dump_rna_messages` code, by
first listing all 'valid' classes, and then processing them all at once
in a flat iteration.
RNA classes are still generated from class hierarchy rooted on the
'virtual' `rna_struct` one, except for operators. These are now
generated by introspecting `bpy.ops` instead.
The extensions spec says this should use semantic version,
so it should always start with X.Y.Z numbers.
Co-authored-by: Campbell Barton <campbell@blender.org>
Pull Request: https://projects.blender.org/blender/blender/pulls/122687
- `bpy.types.Material.blend_method` aliases `bpy.types.Material.surface_render_method`.
'Opaque' and 'Alpha Clip' maps to deferred.
- Renamed `show_transparent_back` to `use_transparency_overlap`
- Renamed `use_screen_refraction` to `use_raytrace_refraction`
- Deprecate `use_sss_translucency` and `use_sss_translucency`
Related to: #113976
**NOTE**
The light probe changes will be done in a different patch.
Both patches should land just before we remove EEVEE Legacy
from the code-base.
Pull Request: https://projects.blender.org/blender/blender/pulls/122297
- 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.
When a user has downloaded an add-on as a zip file, it's not clear in
advance if this is a legacy add-on or a new extension. So they would
have to use trial and error, or inspect the zip file contents.
This uses a simple heuristic to check if the file is a legacy add-on,
and if so automatically calls the legacy operator instead.
The operator now show both extension and legacy add-on properties,
with the latter in a default collapsed subpanel.
Pull Request: https://projects.blender.org/blender/blender/pulls/121926
Extract
- Add to Quick Favorites tooltip.
- "Mask", the name of a newly created mask (DATA_).
- "New" in the context of the new mask ID button.
- A few strings using BLI_STR_UTF8_ defines were not extracted.
Take the special characters out of the translation macros.
- "External" menu items from the filebrowser's Files context
menu (right-click on a file). These items were already extracted,
but not translated.
Improve
- Separate formatted error message "%s is not compatible with
["the specified", "any"] 'refresh' options" into two messages.
Disambiguate
- Use Action context for new F-modifiers' names. This is already used
for the "type" operator prop.
- Translate ImportHelper's default confirmation text using the
Operator context, as it uses the operator name which is extracted
with this context.
- "Scale" can be a noun, the scale of something, or a verb, to scale
something. The latter mostly uses the Operator context, so apply
this context to verbs, and the default contexts to nouns.
- "Scale Influence" can mean "Influence on Scale" (tracking
stabilization) and "to Scale the Influence" (dynamic paint canvas).
- "Object Line Art" as type of Line Art to add, as opposed to the
active object's Line Art settings.
- Float to Integer node: use NodeTree context for the node label, as
this is already extracted and used for the enum.
Do not translate
- Sequencer labels containing only a string formatting field.
Some issues reported by Gabriel Gazzán and Ye Gui.
Pull Request: https://projects.blender.org/blender/blender/pulls/122283
An extension's optional "tagline" field is equivalent to a legacy
add-on's "description". This allows exposing the tagline as a
description in `bl_info`.
The main goal of this change is to expose extension taglines to the
translations, since the legacy description was already extracted.
Pull Request: https://projects.blender.org/blender/blender/pulls/122327
Some UI elements (row and column) can define a heading text.
Optionally, this text can use a custom translation context specified
through `heading_text`. This changes allows extraction of those
headings using the appropriate context instead of the default one.
Pull Request: https://projects.blender.org/blender/blender/pulls/122326
Strings built by concatenating literals and pre-processor-defined
strings would lock the code extracting them for i18n forever.
This commit 'fixes' the issue by adding some support for these cases in
the `inbetween` regex snippet part of the 'extract string' complex regex
system, to avoid the lock.
The code has no way currently to extract the value of these defines
though, so they should not be used in translated strings.
NOTE: PR !122283 should do a propoer fix to these issues, by refactoring
the string building such that only actual strings pieces get processed
by the translation code.
- Allow versions from bl_info to be strings
Versions are now allowed to be strings in extensions using
blender_manifest.toml, so this commit prevents them from being badly
formatted on extraction to add-on translations.
- Do not export Blender copyright text to add-on translations
This text is only relevant for Blender and maybe core add-ons, not
for the general case.
- Copy comment lines from add-on .po files to .py translations
Without this comments added by translators could be lost since they
were not copied over to the Python files.
- Fix indentation in add-on translations
Some lines in the translation dict were off by a few spaces. This
resulted in linting tools complaining about the indentation.
- Do not escape messages in add-on translations multiple times
When extracting add-on messages, they would get escaped multiple
times, resulting in invalid strings when they contained quotes for
example.
This happened because on updating the messages from the ref
ones (those actually extracted from Blender), each ref I18nMessage
would be assigned to the corresponding language I18nMessage, without
copy. When this message was escaped, it happened once for every
language since they were actually the same object.
To avoid this, I18nMessage objects are copied when merging.
-----
Example tuple before PR:
```python
translations_tuple = (
(("*", ""),
((), ()),
("fr_FR", "Project-Id-Version: AnimAll 0...1.1...0 (0)\nReport-Msgid-Bugs-To: \nPOT-Creation-Date: 2024-05-26 17:10+0000\nPO-Revision-Date: YEAR-MO-DA HO:MI+ZONE\nLast-Translator: FULL NAME <EMAIL@ADDRESS>\nLanguage-Team: LANGUAGE <LL@li.org>\nLanguage: __POT__\nMIME-Version: 1.0\nContent-Type: text/plain; charset=UTF-8\nContent-Transfer-Encoding: 8bit",
(False,
("Blender's translation file (po format).",
"Copyright (C) 2024 The Blender Authors.",
"This file is distributed under the same license as the Blender package.",
"FIRST AUTHOR <EMAIL@ADDRESS>, YEAR."))),
),
(("*", "\\"Location\\" and \\"Shape Key\\" are redundant?"),
(("extensions/user_default/animall/__init__.py:250",),
()),
("fr_FR", "",
(False, ())),
),
...
```
After:
```python
translations_tuple = (
(("*", ""),
((), ()),
("fr_FR", "Project-Id-Version: AnimAll 0.11.0 (0)\nReport-Msgid-Bugs-To: \nPOT-Creation-Date: 2024-05-26 17:06+0000\nPO-Revision-Date: YEAR-MO-DA HO:MI+ZONE\nLast-Translator: FULL NAME <EMAIL@ADDRESS>\nLanguage-Team: LANGUAGE <LL@li.org>\nLanguage: __POT__\nMIME-Version: 1.0\nContent-Type: text/plain; charset=UTF-8\nContent-Transfer-Encoding: 8bit",
(False, ("FIRST AUTHOR <EMAIL@ADDRESS>, YEAR.",))),
),
(("*", "\"Location\" and \"Shape Key\" are redundant?"),
(("extensions/user_default/animall/__init__.py:250",),
()),
("fr_FR", "",
(False, ())),
),
...
```
Pull Request: https://projects.blender.org/blender/blender/pulls/122273
