Support for plugins

[Times-Z]

Hi there,

First of all, thank you for developing Wayle!
It’s a very promising project and I really enjoy the simplicity of the current TOML configuration

I’m writing to start a discussion about expanding the current module system
While modules.custom are great for shell scripts (or python scripts), they have some limitations when it comes to complex state management, high-frequency updates, or deep system integration

The Proposal

I would like to propose the introduction of a native plugin system
This would allow users to develop custom modules directly in Rust, which could be loaded by Wayle to provide a more integrated and performant experience

I'm not very familiar with the rust ecosystem yet, but from what I've read and seen elsewhere, it's feasible

Possible Implementations

• Dynamic Loading (.so files): Using something like libloading to load compiled plugins at runtime without needing to recompile the main Wayle binary

• Plugin Trait/SDK: Defining a WaylePlugin trait in a shared crate that developers can implement, requiring a recompile but offering maximum safety

• WASM Integration: Using a runtime like Wasmtime to run plugins compiled to WebAssembly (as seen in projects like Zellij)
  |
  => From what I understood this would be the best way to implement plugins

Why "native" plugins?

• Performance: No overhead from spawning shell/python processes for frequent updates

• Safety & Types: Leverage rust’s type system for more robust modules compared to shell/python scripts

• Rich Integrations: Easier access to the rust ecosystem (async tasks, dbus, etc.)

• Complex UI/UX: Ability to create more dynamic widgets that might be hard to define via static TOML

I’d love to hear your thoughts on this:

• Does this align with the long-term vision of Wayle (keeping it simple vs. making it extensible)?

• Would you prefer a dynamic loading approach or a "compile-time" plugin system?

• Are there specific architectural constraints we sould keep in mind ?

[Dieterbe]

What would be the evaluation criteria for a plugin system?

some suggestions:

• performance (latency, cpu usage): less overhead is better
• ease of moving modules in/out of core: i like the idea that popular external plugins could become mainline, or core plugins can be moved out if they're not maintained, so this suggests using the same API's/interfaces between core modules and plugins.

[Times-Z]

I'm currently reading some documentation/threads to have some point on that, at moment for me :

• Performance & overhead ofc
• Async support
• Safety & maintenance :
  As you mentioned, the API should be the same. If we go with a trait-based approach, we could provide a wayle-plugin-sdk crate
  This would:
  • Enforce type safety
  • Define a clear lifecycle (e.g., on_init(), on_update(), on_click())
  • Allow the core to handle panic recovery if a plugin fails
• ABI stability : Rust doesn't have a stable ABI. We should decide if we want to use repr(C) for the plugin interface or if we force plugins to be compiled with the same compiler version as Wayle to avoid memory layout issues
• Scoped access : Define what a plugin can access

I like the idea of plugins being able to move to the core; I'll keep that in mind ! Maybe Jas already has some thoughts on this? I'm looking forward to his review 😁

[Times-Z]

I'm currently spending so much time (as my girlfriend says lol) to implement a POC and have a big picture view of what I would like to have

After ~2 big night I have a WASM implementation working with a basic plugin for updates with a custom dropdown
The first one (left) is the current implementation of custom with a bash script, the second (right) is the WASM one
I try to make this public by next week

https://youtu.be/XT8TlOnJazg

[Dieterbe]

I'm currently spending so much time (as my girlfriend says lol)

tip: use an AI assisted IDE (i personally use windsurf but there's many of them), it can really help speed up development! Also feel free to join us on discord to discuss more.

video looks nice, but it'll all depend on the implementation of course

[Times-Z]

Ok, I tried to implement a version with a security model

You can read documentation here (claude generated at moment) : https://github.com/Times-Z/wayle/blob/feature/plugins-base/docs/config/SDK/SDK.md

And you can have a plugin example here : https://github.com/Times-Z/wayle-plugin-update

https://youtu.be/YVQmzGUF77c