Installing add-ons and plugins

"Geometry and add-ons" showed the Results Analysis add-on, bundled with Konjugate from the start. This page covers the other way an add-on, or its numerical counterpart, a plugin, ends up in the workbench: installed from a portable file rather than shipped with the app.

The two are distinct file types with distinct jobs. A .kja file installs an add-on: a visualizer that reads a result and renders it in its own window. A .kjp file installs a plugin: numerical behavior, such as a relationship provider written in Python or C++, or a reusable component template for the node library. Both are portable, both are reviewed before anything is written to disk, and neither runs any code just by being installed.

Where installed packages live

Every installed and bundled package is listed in one place: Extensions, opened from its own button in the title bar.

Add-ons and plugins get their own tabs here. Each entry names its version and where it came from: Bundled for something Konjugate ships with, Installed for something added from a .kja or .kjp file. Nothing about using a bundled package differs from using an installed one once it's loaded, the distinction is only about where it came from and whether it's yours to remove.

Installing one

Install…, in the footer of this same dialog, opens the operating system's own file picker, filtered to .kja and .kjp files. Choosing one doesn't install it immediately: a confirmation dialog names the package, its publisher's package ID, its type and the exact permissions it's requesting. Installation only proceeds if that's approved.

Before anything is extracted, Konjugate checks the archive itself: its declared type matches its extension, its size and file count stay within limits, its manifests are present and well-formed and no entry path escapes its own installed folder. A failed check, or a canceled confirmation, leaves nothing behind.

Reviewing what's installed

Selecting an entry shows exactly what was reviewed at install time, still available to check back on later.

Package ID is the stable identifier used wherever this specific package gets referenced, the same value a project's relationship would pin a plugin's provider to. Permissions lists exactly what the package can access, decided once at install time rather than expanding quietly later.

Plugins look the same, do something different

Switching to the Plugins tab shows the same list-and-detail layout, for a different kind of package.

Installing a plugin doesn't run its code, and neither does anything else, until a project explicitly references it. A relationship's implementation can point at a plugin's provider by ID and pinned version; only then does the engine ever launch it, during validation or a run.

Disabling vs. uninstalling

Every installed or bundled entry has a toggle between Disable and Enable: disabling keeps the package on disk but stops Konjugate from loading it, without deleting anything. Uninstall removes it from disk entirely, and only appears for installed packages: a bundled one ships with the app and isn't yours to remove.

Where to go from here

Writing an add-on or a plugin, rather than installing one someone else built, is developer territory covered in the project's own repository documentation, not this series. From here, "Geometry and add-ons" covers what a bundled add-on looks like in use, and "The model assistant" covers another place a plugin-style provider configuration gets chosen and reviewed before it runs.