Nexus
Runtime architecture and responsibilities
Understand how the framework connects pages to Blender and which public layers add-on authors can depend on.
Roles of interface, application, and runtime
Authors build web pages and Python logic and embed the framework. Shared runtime components supply local programs for web execution. Together they form a working Blender interface.
| Responsibility or process | Instructions |
|---|---|
| Your web page | Layout, controls, local state, and feedback; requests application work through public page APIs. |
| Your Python logic | Reads and modifies Blender data, validates arguments and targets, registers actions and state, and emits events. |
| Nexus UI Web framework | Manages windows, clients, messages, and resources, forwarding public calls to the active service. |
| Shared runtime components | Local programs for web execution and frame transport, installed according to platform and protocol requirements. |
Website demos simulate interactions without running your add-on. Use trusted local add-on pages in Blender for real work.
From opening a window to its first frame
- The add-on submits page, size, and target-region declarations through public APIs.
- The active service validates sources, paths, runtime conditions, and editor ownership.
- A session creates the web surface, and the runtime browser executes HTML, CSS, and JavaScript.
- Platform frame transport and rendering display the page inside a Blender editor.
Valid declarations, located runtime components, first frames, and usable application features are separate checkpoints. This is not simply embedding a standalone desktop browser window. Editor changes affect ownership. For parameters, see Window and page declarations.
Rendering and application messages have separate roles
| Responsibility or process | Instructions |
|---|---|
| User input → page | The host routes pointers, keyboard, and input methods according to hit testing, focus, and press ownership. Header handles may move the window through the host. |
| Page → Python | Actions carry requests and JSON arguments. Handlers validate, execute, and return results. |
| Python → page | State gives current facts; events announce occurrences; resource references carry images and larger data. |
| Page → continuous scene transforms | Dedicated transform interactions manage preview, commit, and cancellation. Results still require checking. |
Button animation does not prove Python ran, and scene changes do not prove a new snapshot reached the page. See Actions and state integration.
Framework copies and shared services
Each add-on carries a complete framework copy and binds through public APIs. Coordination selects an active service rather than independent unaware private services. Runtime responsibilities are shared; users need not install a separate shared framework add-on.
Clients, actions, and resources remain scoped to their add-ons. Selection uses framework identity and compatibility, not display names or enable order. Active services are not forcibly hot-replaced. See Restarts and identity conflicts.
Documents, windows, and add-ons have different lifetimes
- Reloading creates a new document. Old subscriptions, temporary resources, and asynchronous operations are not data for the new document.
- Closing cleans up the window session; switching a page component cleans up only its owned listeners and gestures.
- Disabling releases your clients and registrations, not services still used by other add-ons.
- Browser persistence controls cache and cookies, not all JavaScript memory or application data.
For cleanup details, see Client lifecycle and Core page API.
What add-on authors may depend on
Copy nexus_web and use public nexus_web and nexus_web.web APIs. examples is learning material. Internal host/runtime/native bridges and caches are not stable application APIs. Importing stays lightweight; registration, binding, and opening are separate stages.
Page styling and documentation changes do not require runtime rebuilding. Native or protocol changes need platform-specific builds and verification. Source inspection, static preview, real input, and application testing do not substitute for one another.