Salamatrix Extension Framework

[KRtekTM]

Salamatrix Framework – multi-language extensions for Open Salamander

I have been working on Salamatrix, a new extension framework developed as part of my Samandarin fork.

Salamatrix is intended to fill the space between simple one-shot Automation scripts and full native C++ plugins. It provides a shared, versioned service layer that extensions can use regardless of their implementation language.

The framework currently includes:

• extension manifests, lifecycle and dependency handling;
• access to Salamander panels, tabs and selection context;
• commands and native file operations;
• events and per-extension persistent storage;
• integration with Plugin Manager, plugin menus, context menus and a configurable Extension Bar;
• standalone runtime providers for Python, PowerShell, PHP, Node.js and Lua;
• compatibility with existing Automation JScript and native C++ callers.

Out-of-process runtimes communicate with Salamander through the bounded SMX1 worker protocol instead of exchanging native pointers.

A major part of the framework is Salamatrix.UI. Extensions written in any supported language can construct real Salamander dialogs using the same control model. Salamander remains responsible for the actual native windows, dark mode, DPI scaling, keyboard navigation and host-specific controls, so runtime providers do not need to integrate separate GUI toolkits.

The same UI capabilities dialog is currently implemented independently in Node.js, Python, PowerShell, PHP, Lua, Automation JScript and native C++.

---

Salamatrix is still an evolving MVP and is not intended to replace the native Plugin SDK. Native plugins remain appropriate for deep integration and performance-sensitive functionality. The goal is to make smaller and medium-sized extensions considerably easier to develop while still allowing them to look and behave like native parts of Salamander.

Framework overview and current implementation status:

https://samandarin.krtkovo.eu/salamatrix/index.html

Salamatrix.UI documentation and examples:

https://samandarin.krtkovo.eu/salamatrix/salamatrix-ui.html

Feedback on the architecture, APIs and possible extension use cases is welcome.

[janrysavy]

One thought comes to mind: in today’s world, does it still matter which programming language a plugin is implemented in?

[KRtekTM]

From the user’s point of view, probably not — a plugin should simply work and integrate well with Salamander.

From the extension developer’s point of view, I think the language still matters quite a lot. It determines the available libraries, tooling, debugging experience, deployment model, performance characteristics and, most importantly, the entry barrier. Native C++ is still the right choice for deep integration and performance-sensitive plugins, but it can be disproportionate for a small utility that could be implemented in a few dozen lines of Python, PowerShell or JavaScript.

The goal of Salamatrix is therefore not to make the choice of language itself the main feature. It is to make that choice largely irrelevant to Salamander. All runtimes use the same host services, lifecycle, UI model and integration points, while extension authors can use the environment most appropriate for the task and their existing experience.

The implementations in several languages are mainly a demonstration that the framework contract is genuinely runtime-neutral, rather than being a JavaScript or Python API with additional languages added as an afterthought.

AI can of course generate C++ today, but it does not completely remove the differences in build systems, dependencies, debugging, deployment and long-term maintenance. For smaller extensions, avoiding the native toolchain can still make the difference between somebody creating an extension and not creating one at all.

[KRtekTM]

BTW I am also experimenting with Salamatrix AI, a companion tool using locally running LLaMA and Qwen2.5-Coder models. Its purpose is to help users create scripts and automate Salamander workflows through natural-language instructions, without requiring programming knowledge or having to write the code themselves. This is still a very early prototype and will require substantial testing, refinement and further development before it becomes practically reliable.