Based on feedback in !122727, include previously built-in add-ons
in the built-in extensions panel even if there is no support for
adding it back via the extensions repository.
This groups all the add-ons from 4.1 which were enabled but are no
longer distributed with Blender and provides an easy way for users to
install them. This panel is collapsed by default.
Ref !122727
Co-authored-by: Dalai Felinto <dalai@blender.org>
Replace LZMA with ZLIB compression as default tools on Linux & Windows
can't decompress these ZIP files and some users wish to open and inspect
the extensions.
While LZMA has the potential for significantly better compression it
turns out the actual gains were marginal for extensions that contain
many Python files (compared with `tar.lzma`) because each file is
compressed individually, see #122710.
Scanning the file-system for paths to include didn't detect cases when
explicitly included paths (such as wheels) were missing.
Change the logic to build a list of paths which is merged with pattern
matched paths (de-duplicating), then add all files into the ZIP.
Any missing paths will raise an error.
We don't do anything with the content of the dictionary yet (the reason
why each permission is required. But Blender can talk again with the
extensions server.
This still requires changes on the validation and build and
server_generate commands. To be tackled separately.
Light redesign of the extension/add-on list item.
The last time this layout was updated was in Blender 2.5, when text was
usually left-aligned, and add-ons preferences weren't streamlined yet.
The goal is to keep a familiar look, while making some improvements to
organization such as group actions (install/uninstall, buttons to external sources
like website, documentation, report a bug).
Detail images available in the pull request.
Pull Request: https://projects.blender.org/blender/blender/pulls/122726
* Move missing script files inside a panel.
* Call it Missing Add-ons.
* Add an explicit "X" to dismiss (instead of the checkbox).
Note: The panel is collapsed by default.
Co-authored by Pablo Vazquez.
Pull Request: https://projects.blender.org/blender/blender/pulls/122721
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
- All remote repositories are included in the check for outdated
packages, the check-for-updates setting is only used to sync with
the remote before checking for outdated packages.
- Defer checking for repositories to notify until after Blender
has opened since checking for installed packages & outdated
repositories could add some noticeable overhead.
Move extension update display from the splash screen to the status bar.
Based on !122413 with minor changes & removal of splash text.
Co-authored-by: Harley Acheson <harley.acheson@gmail.com>
This was probably borked during one of the recent renames.
To reproduce the original issue:
* Go to Preferences > Extensions
* Check the console:
rna_uiItemO: unknown operator 'extensions.show_online_prefs'
4.2/scripts/addons_core/bl_pkg/bl_extension_ui.py:354
Replace use of "bl_pkg" operator category with "extensions",
this naming was used while the functionality was experimental,
not intended to be used once extensions was moved out of experimental.
Being offline shouldn't be considered an error which checking for
updates on startup, so connectivity issues are suppressed unless
running in debug mode.
Ref !122463
It's possible the user frees or change the repository after a check
for updates starts because synchronizing repositories isn't blocking.
Resolve by using a copy of the repository when checking for updates,
only applying updates if the copy still matches the preferences once
the update is complete.
When online mode is enabled and the preferences are shown,
the users needed to manually check for updates.
Now this runs in the background, sharing logic with checking for
updates on startup.
When updates run status text is currently shown in the preferences
window, eventually this should be displayed in the status bar.
To avoid conflicts when updating a queue is used to avoid problems
caused by check for updates on startup & the preferences window also
checking for updates. Since checking for updates is optional it's
possible some repositories wont be handled by checking on startup
so both updates run for now. De-duplicating update checks can be
supported eventually.
