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 ways something ends up in the workbench from outside it: an add-on or plugin installed from a portable file, and an FMU imported from elsewhere entirely.

There are three distinct file types here, with three 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. A .fmu file imports a compiled FMI 2.0 or 3.0 Co-Simulation component, third-party or Konjugate's own, as a computational node a model can reference. All three are portable, all three are reviewed before anything is written to disk, and none of them 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, plugins and FMUs each get their own tab here. Each entry names its version and where it came from: Bundled for something Konjugate ships with, Installed for something added from a 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, .kjp and .fmu files together, whichever tab happens to be open. 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.

FMUs are a third kind

The FMUs tab holds a third, unrelated kind of import: a real FMI 2.0 or 3.0 Co-Simulation component, either exported from Konjugate itself or built by someone else's tooling entirely.

An FMU has no permissions to review, since it isn't Konjugate code at all: it's a compiled binary the engine drives directly through the standard FMI C API, not something that can declare access to Konjugate's own capabilities the way an add-on or plugin manifest does. Its Package ID is the guid the FMU's own modelDescription.xml carries, which is how Konjugate recognizes the same FMU reinstalled later or referenced by a project. Once installed, a node's implementation can reference it by that guid and version, exactly like referencing a plugin's provider. Unlike an add-on or plugin, this takes effect immediately, with no restart needed.

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.