Nexus
Integrate into an existing Blender add-on
Keep existing features and entry points while connecting a new web interface to your Python logic.
Decide whether integration is worthwhile
Suitable for tools needing flexible layouts, custom appearance, or existing frontend components. For a few standard controls, native panels may be simpler and require less web/runtime maintenance.
Integration means maintaining pages, Python logic, communication, and matching runtime components. Check Supported platforms and preparation, then follow the documentation to integrate your pages and application logic.
Style the page while keeping existing business functions, called through public actions; Actions and state tutorial explains updating results in the interface. The framework does not automatically migrate UI or rewrite logic.
Start with an independently testable feature
Connect the page to existing logic through one independent window or a small focused panel, such as object information. Migrating an entire complex add-on at once changes too many entry points and behaviors to diagnose easily.
If the add-on already uses Nexus UI Web, go to Continue development and diagnose problems. Do not overwrite it with another template copy.
Check existing structure first
- Identify source and the actually loaded Blender copy; update through existing synchronization or installation.
- Locate registration, unload, panels, menus, and logic. Decide whether the entry is added or replaced.
- Legacy add-ons with bl_info but no blender_manifest.toml need a separate decision about modern extension migration, which changes installation and delivery.
- Check existing framework copies and versions; integration is not an unplanned upgrade.
Integrate in this order
- Preserve manifest identity, version, and application files. Merge the framework path section and explain network/files permissions for runtime downloads and local packages.
- Follow Obtain the framework to copy the framework, not the entire repository.
- Add local pages/assets individually to the manifest.
- Register the framework, reuse one client, declare the window, and add a panel/menu entry.
- Register actions after binding. Call existing functions and return needed data rather than duplicating logic.
- On unload, remove entries and callbacks, release clients, then unregister.
Preserve existing business semantics
Mode, active-object, and undo requirements still apply. Bridge context is not bpy.context; identical parameter names do not make them interchangeable.
Start read-only to verify entry and communication before writes. See Build your first add-on; for arguments, errors, and refresh, see Call Python from the interface. Native panels and web windows can coexist, but not mix their controls inside one window.
Verify old and new workflows
| Check | Expected result |
|---|---|
| Original entry | Existing features, shortcuts, and cleanup remain functional. |
| New window | The entry follows its open/close contract and reopens after page-side closing. |
| Application actions | Invalid modes or missing targets give reasons; successful writes change real data. |
| Disable and restart | No leftover panels, timers, or duplicate registrations. |
| Replacing the old UI | Verify the feature in reality before deciding whether to remove its old entry. |
Source inspection or a visible window alone does not prove migration success. Registration and cleanup and Packaging and delivery covers subsequent steps.