I have a plugin trait that includes some heavy types that would be almost impossible to wrap into a single API. It looks like this:
pub struct PluginContext<'a> {
pub query: &'a mut String,
pub gl_window: &'a GlutinWindowContext,
flow: PluginFlowControl,
pub egui_ctx: &'a Context,
disable_cursor: bool,
error: Option<String>,
}
pub trait Plugin {
fn configure(&mut self, builder: ConfigBuilder) -> Result<ConfigBuilder, ConfigError> {
Ok(builder)
}
fn search(&mut self, ui: &mut Ui, ctx: &mut PluginContext<'_>);
fn before_search(&mut self, _ctx: &mut PluginContext<'_>) {}
}
Here is what I considered:
- Keeping all plugins in-repo. This is what I do now, however I'd like to make a plugin that would just pollute the repository. So I need another option that would keep the plugins' freedom as it is right now, but with the possibility to move the plugin out to a separate repository.
- I tried to look into dynamic loading, and since rust doesn't have a stable ABI, I'm okay with restricting the rust versions for the plugin ecosystem. However, I don't think it's possible to compile this complex API into a dynamic lib and load it safely.
- I'm also ok with recompiling the app every time I need a new plugin, but I would like to load these plugins automatically, so I don't want to change the code every time I need a new plugin. For example, I imagine loading all plugins from a folder. Unfortunately, I didn't find an easy solution for this neither. I think I will write a build macro that checks the
~/.config/myapp/pluginsand include all of them into the repo.
Do you have any better ideas, suggestions? Thanks in advance.
(For context, this the app I'm writing about: https://github.com/fxdave/vonal-rust)
well, yes, but for e.g. I wrote a software piece that happened to be only a hotkey daemon. And I could write it with X. Now, hotkey daemons are no longer a separate thing unless the compositor exposes a grab API. Which never going to be in Wayland protocol, because they consider this client server architecture a problem.