Legacy feature-gap audit

This audit compares the current Blender Development pre-release with the legacy main-legacy implementation. It identifies user-visible capabilities that have not yet been reintroduced while avoiding false gaps where the current plugin already provides the same outcome through newer IntelliJ Platform or PyCharm APIs.

The comparison was completed on July 22, 2026. It covered registered plugin extensions and actions, Kotlin and Python implementations, templates, tests, changelogs, and project documentation. Generated build output and third-party payloads were excluded.

Technical terms with a dotted underline include source evidence. Focus or hover over a term to see its repository-relative path, or follow the link to open that file on Codeberg.

Summary

Result	Count	Main themes
High-priority gaps	3	Managed Blender installations, isolated launches, and extension packaging workflows
Medium-priority gaps	7	Project variants, generated configurations, multi-source operation, Run-mode reloading, and manifest options
Low-priority gaps	6	IDE affordances, optional scaffolding, and consolidated diagnostics

The current plugin already has the stronger core run/debug architecture. It provides PyCharm debugger attachment, session-aware runtime commands, per-project environment variables, installation discovery, and version-matched Blender API stubs. The largest remaining gaps surround that core workflow: acquiring Blender, isolating its state, packaging extensions, and supporting alternate project layouts.

Capability matrix

ID	Legacy capability	Current status	Result
FG-01	Download, verify, extract, cache, and delete managed Blender versions	Settings can download, extract, detect, and delete managed versions; checksum verification remains	Partial
FG-02	Project-local Blender sandbox, optional user-config import, custom splash, and cleanup	No managed sandbox	Gap
FG-03	Build, validate, and arbitrary Blender CLI run-configuration modes	Blender launch configuration only	Gap
FG-04	Classic single-file add-on project generator	Package-oriented `src` generator only	Gap
FG-05	Automatic Start, Build, and Validate configuration creation	Configurations are not generated	Gap
FG-06	Multiple extension source folders linked in one project	One configured extension source folder	Partial
FG-07	Automatic extension reload during normal Run sessions	Reload on save is limited to Debug	Partial
FG-08	Optional automatic class-registration scaffold	Explicit registration only	Gap
FG-09	Manifest platform filters and build exclusion patterns in the wizard	Not exposed or generated	Gap
FG-10	Persistent catalog of multiple named custom Blender installations	One project-specific custom path	Partial
FG-11	Connection status-bar widget	No status widget	Gap
FG-12	`.blend` file and marked source-folder icons	No Blender-specific icon provider	Gap
FG-13	Blender operator and panel live templates	Full-file templates only	Gap
FG-14	New Blender package action that creates a package and `__init__.py`	File templates only	Gap
FG-15	Post-creation project repair and scaffolding commands	Initial wizard generation only	Gap
FG-16	Consolidated offline launch-environment diagnostic snapshot	General and runtime logging only	Partial

High-priority gaps

Managed Blender installation lifecycle

The legacy BlenderDownloader could download supported Blender versions, fetch and check Blender’s SHA-256 manifest, extract the archive into managed storage, locate the executable, reuse cached installations, report progress, and delete installed versions.

The current installation workflow can download, extract, detect, and delete managed Blender versions from Settings > Tools > Blender Development. The installation scanner refreshes the shared installation list after a managed change. Published archive checksum verification is not implemented yet.

User impact: Supported Blender versions can be managed from PyCharm, but this pre-release workflow does not yet verify the downloaded archive against Blender’s published checksum.

Project-local Blender sandbox

The legacy BlenderLauncher could redirect Blender configuration, scripts, and data into a project-local sandbox. It also supported importing selected user preferences, applying a project splash image, excluding the sandbox from indexing, and clearing the sandbox from the UI.

The current launcher supports environment variables and additional script directories, but it does not construct an isolated Blender home or configuration area.

User impact: launches can depend on and affect the user’s normal Blender configuration, which reduces isolation and reproducibility.

Extension build, validation, and generic commands

The legacy run-configuration type offered Start Blender, Build Extension, Validate Extension, and arbitrary Blender Command modes. Its profile state supplied Blender’s extension CLI with source and output paths.

The current configuration type registers one launch factory for Run or Debug and does not expose packaging or validation as first-class IDE workflows.

User impact: extensions cannot currently be built or validated through Blender Development’s run configurations.

Medium-priority gaps

Single-file add-on projects

The legacy plugin registered a single-file project generator for classic add-ons. It exposed legacy bl_info fields such as location, warning, documentation URL, category, Blender version tuple, and optional example code.

The current generator creates a src/__init__.py project and can optionally add an extension manifest. It does not offer a root-level single-file layout.

Generated run configurations

Legacy project generators created Start Blender, Build, and Validate configurations with the selected version, source path, module name, and sandbox preference. A project service could recreate them later.

The current wizard stores project settings but requires the user to add a Blender configuration through Run > Edit Configurations.

Multiple extension source folders

The legacy project state could mark several folders as Blender sources, and BlenderLinker linked each source into Blender’s extension repository. The current project state has one extension source folder and one add-on or extension name.

The current Script directories list expands Blender’s script search path, but it is not equivalent to independently managing and reloading several extensions.

Reload on save during Run

The legacy save listener could request a reload from ordinary launch workflows. The current reload-on-save listener is installed by BlenderDebugProgramRunner and is scoped to Debug sessions, where the full runtime command channel is available.

Reload on save during Debug is already supported and is not a gap.

Automatic registration scaffold

The legacy project template generator could generate an auto_load.py helper that discovered and registered Blender classes automatically. The current example template uses an explicit class tuple and register()/unregister() functions.

Manifest platforms and build exclusions

The legacy extension wizard accepted platform filters and build-path exclusion patterns for blender_manifest.toml. The current wizard state covers extension identity, type, version range, license, website, tags, and permission reasons, but it does not expose these two build/distribution options.

Named custom Blender installations

The legacy settings state stored multiple custom executable paths as reusable named entries. The current manager supports discovered installations or one custom path for the active project.

Low-priority gaps

The legacy status-bar widget distinguished connected, running but disconnected, error, and not-running states. The current plugin communicates runtime state through action availability, notifications, and logs.

Project-view icons

The legacy icon provider assigned Blender-specific icons to .blend files and marked extension source folders. The current plugin does not register an equivalent provider.

Operator and panel live templates

The legacy plugin included Python live templates for Blender operators and UI panels. The current Main Script and Component templates create complete files but do not provide in-editor snippet expansion.

Blender package creation

The legacy New Blender Package action could create a package directory and render __init__.py in one operation. The current Blender template group creates files but does not create a package structure as one action.

Post-creation scaffolding

The legacy tool window could add or repair Git ignore rules, a GPL license, generated run configurations, and an optional local AI-agent guidance pack after project creation. The current wizard generates the main repository files initially but does not offer repair commands.

The legacy agent pack should be reconsidered against current IDE and Codex conventions before any reimplementation.

Consolidated environment diagnostics

The legacy offline telemetry service recorded one diagnostic block containing the operating system, architecture, memory, Java version, sandbox state, Blender and Python versions, API-stub status, and launch options.

The current plugin has more focused scanner, launch, command, and Blender runtime logging, but it does not produce one consolidated environment snapshot.

Capabilities that are not gaps

The following legacy outcomes already exist or have been superseded:

Capability	Current result
Cross-platform Blender discovery	Current scanner provides the same outcome with richer diagnostics and cached application-level results
Launching and synchronizing project code	Run and Debug both launch Blender and refresh or load the configured project
Blender Python debugging	Dedicated Debug runner, session coordination, automatic PyCharm attachment, and Just my code support
Reload on save during Debug	Lifecycle-scoped listener is installed for the Debug process
Manual add-on reload	Session-aware runtime action resolves extension manifest IDs
Run a selected Python script	Available from the Tools menu and Python editor context menu
Stop an active Blender process	Available as a runtime command
Python environment creation and selection	Delegated to PyCharm’s native Python project workflow
Version-matched Blender API stubs	Installed into the selected interpreter and recorded in `pyproject.toml`
Core manifest and repository scaffolding	Current wizard generates metadata, permissions, licensing, README, and Git ignore content
Launch customization	Current project settings add arguments, environment variables, log level, repository name, and script directories

Historical claims of 11-language localization are also not counted as a gap. The audited legacy branch contains only its base message bundle and no locale-specific bundles.

Recommended sequence

Decide whether Blender Development should own managed Blender downloads and project-local sandboxes. Both features create long-term security and maintenance responsibilities.
Add Build and Validate workflows on top of the current run-configuration and project-state architecture.
Generate the supported configurations from the project wizard.
If Run-mode hot reload is desired, establish the runtime session in both Run and Debug while keeping debugger attachment conditional.
Decide whether projects support one extension, several extension roots, classic single-file add-ons, or automatic registration before expanding project state.
Add platform filters and build exclusions to the extension wizard.
Treat status indicators, icons, snippets, package creation, diagnostics, and repair commands as independent follow-up improvements.