GSoC 2026 Proposal Idea: Strengthening InVesalius Plugin System

[AnvayKharb]

Hi @tfmoraes @paulojamorim @tatiana

While exploring the InVesalius codebase, I noticed that a plugin infrastructure already exists (plugins.py and the plugins/ directory), but it appears incomplete and largely undocumented. At the same time, several recurring or experimental features (custom tools, exporters, utilities) seem more appropriate as extensions rather than changes to the core application—especially given InVesalius’ safety-critical nature.

This raises the question of whether improving the plugin system itself could be a valuable direction, enabling extensibility while keeping core medical logic stable and isolated.

---

Motivation

A well-defined plugin architecture could:

• Reduce pressure on core code for experimental or optional features
• Improve maintainability by isolating non-essential functionality
• Enable community contributions without risking core stability
• Provide a clearer path for future feature growth

The goal is not to introduce new medical functionality, but to improve the infrastructure that supports safe extension.

---

Proposed Direction (High-Level)

The idea I’d like to discuss focuses on making the existing plugin system more complete, reliable, and developer-friendly:

• Finalizing plugin discovery and metadata validation
• Defining a clear and stable plugin API
• Introducing safe plugin lifecycle management (load, enable/disable, failure isolation)
• Adding a minimal wxPython-based plugin management interface
• Providing documentation and example plugins to demonstrate intended usage
• Adding tests to ensure long-term reliability

This work would aim to keep plugins clearly separated from core medical logic.

---

Open Questions for Maintainers

I’d really appreciate guidance on the following:

• Does strengthening the plugin system align with current project priorities?
• Are there architectural, safety, or regulatory constraints that plugins must respect?
• Is there an existing vision for how plugins should interact with core components?
• Which parts of this direction seem most valuable vs. unnecessary?

---

Possible First Steps

If this direction makes sense, I’d be happy to start with smaller, concrete contributions such as:

• Documenting the current plugin mechanism and its limitations
• Cleaning up or clarifying existing plugin-related code
• Adding a minimal example plugin to illustrate intended usage

---

Intent

This post is meant to start a technical discussion, not to lock in a design prematurely. I’m looking to align with the project’s long-term goals and would value any feedback, critique, or redirection.

Thanks for your time and guidance.

— Anvay