The extensions system allows to extend Blender with connectivity to the internet. Right now it means Blender can
discover and install add-ons and themes directly from the internet, and notify users about their updates.
By default this is disabled (opt-in), and users can enable it the first time they try to install an extension or visit
the Prefences > Extensions tab. If this is enabled, Blender will automatically check for updates for
extensions.blender.org upon startup.
When will Blender access the remote repositories:
* Every time you open the Preferences → Extensions: ALL the enabled repositories get checked for the latest info (json)
* Every time you try to install by dragging: ALL the enabled repositories get checked for the latest info (json).
* Every time you start Blender: selected repositories get checked for the latest info (json).
------------------
From the Blender code point of view, this means that most of the add-ons and themes originally bundled with Blender
will now be available from the online platform, instead of bundled with Blender. The exception are add-ons which are
deemed core functionality which just happened to be written as Python add-ons.
Links:
* Original Extenesions Platform Announcement: https://code.blender.org/2022/10/blender-extensions-platform/
* Extensions website: https://extensions.blender.org/
* User Manual: https://docs.blender.org/manual/en/4.2/extensions/index.html#extensions-index
* Technical specifications: https://developer.blender.org/docs/features/extensions/
* Changes on add-ons bundling: https://devtalk.blender.org/t/changes-to-add-on-bundling-4-2-onwards/34593
------------------
This PR does the following:
* Move extensions out of experimental.
* No longer install `scripts/addons` & `scripts/addons_contrib`.
* Add `scripts/addons_core` to blender's repository.
These add-ons will still be bundled with Blender and will be always enabled in the future, with their preferences
moved to be more closely integrated with the rest of Blender. This will happen during the remaining bcon2 period.
For more details, see #121830
From scripts/addons:
* copy_global_transform.py
* hydra_storm
* io_anim_bvh
* io_curve_svg
* io_mesh_uv_layout
* io_scene_fbx
* io_scene_gltf2
* pose_library
* ui_translate
* viewport_vr_preview
Extra: bl_pkg (scripts/addons_contrib)
Note: The STL (legacy) add-on is going to be moved to the extensions platform. There is already a C++ version on core
which is enabled by default.
All the other add-ons are already available at extensions.blender.org. To use them you need to:
* Go to User Preferences > Extensions
* You will be greated with an "Online Extensions" message, click on "Enable Repository".
* Search the add-on you are looking for (e.g, Import Images as Planes).
* Click on Install
Over time their maintaince will be transferred over to the community so their development can carry on. If you used to
help maintain a bundled add-on please read: https://devtalk.blender.org/t/changes-to-add-on-bundling-4-2-onwards/34593
Ref: !121825
- Suppress progress and waiting for input() when the output
isn't a TTY.
- Use a print_progress utility function that adds trailing space
instead of including is as part of the string.
Since moving to "tools/" the suggested command would modify
headers *outside* Blender's source directory (now prevented).
Since "#pragma once" was used - the duplicate header check
needed to be moved from the end to the start of the header.
Other changes:
- Add type hints.
- Exclude headers intended to be included multiple times.
- Use `argparse` for argument parsing.
- Use str.format.
The python script checks on reports based on the provided severity (default High) and sorts them per module.
Thanks to Sybren for suggestions on how to improve it!
Pull Request: https://projects.blender.org/blender/blender/pulls/120022
This currently contains some types I personally needed
more types can be added if people desire them.
Due to the .natvis being added to creator, Visual Studio
will automatically pick up on these types and show the
improved visualizers while debugging.
vscode can also use this file, but you'll have to check
its documentation on how to set that up.
Pull Request: https://projects.blender.org/blender/blender/pulls/118576
So far this would include commits committed by the given user, but
authored by someone else. Unfotunately we can't use email addresses to
filter these out, since we can't get the email addresses associated with
an account from gitea, or do a user lookup by email. In my testing the
commit author email and the publicly visible account email would
mismatch in most cases.
This much more basic representation of a blendfile is designed to
survive badly corrupted data, e.g. when handling files without DNA
info, etc.
Obviously the amount of data extracted is way less, but it's still
eaiser to analize than dealing with pure binary data.
As this is only added to set strict warnings, cleaning logic would
remove as the compilers output is unchanged.
Support excluding headers from removal, others can be added if needed.
I added a new BLO_userdef_default.h header to contain declarations of
two global variables that are still defined in C files. Use of designated
initializers for large structs make those files harder to change.
Arguably this is a better header for them anyway.
Pull Request: https://projects.blender.org/blender/blender/pulls/118015
