Closed oknozor closed 2 years ago
Very interesting. It'd be useful to include an example in the examples sub-directory of the toolkit package, and the optional methods should have an empty method implementation by default so you don't have to write // not needed
. I'm also wondering if it's really necessary for it to be a feature since the programmer using the toolkit can still choose not to use it.
I have added a default impl for the optional functions as suggested and removed the feature.
I was tempted to copy paste the mpd plugin example but it would be better to implement something a little less specific . I was thinking about pid search and kill.
I will probably update the PR tomorrow.
I don't think the example has to be necessarily useful in any way.
For now, we could have a curated list of third party plugins mentioned in the readme.
In the future, it'd be ideal to have a repository (or branch of this repository) with a file containing machine-readable curated plugin releases that the pop-launcher could use for installing and updating plugins.
I still think the mpd example doesn't fit. You would need to have a running instance of a mpd server on your machine to make the example work.
In the future, it'd be ideal to have a repository (or branch of this repository) with a file containing machine-readable curated plugin releases that the pop-launcher could use for installing and updating plugins.
That would be awesome ! The past few days me and a friend have been looking into alfred workflows collections like this one https://github.com/learn-anything/alfred-workflows, and I we are planning to port a few of them to pop-launcher.
How would you generalize the installation process though ?
We would need the plugin implementors to respect some kind of contract regarding the installation process,
Maybe a justfile "install" recipe ? So we can expect every plugin to be installed the same way.
Then we would just need to git clone plugin && cd plugin && just install
.
Implementing a pop-launcher install/remove plugin
sub command would be trivial then.
Let me know if it suits you, I would be glad to help.
I think it'd be fine to provide a developer flag for installing a plugin from source, but perhaps the curated repository should be maintaining a list of release tarballs and their shasums, extracted directly to the plugin directory into a directory of the name of the plugin. A more restrictive installation process for curated plugins would be ideal from a security perspective.
Just added a simple plugin example that run whatis
on the input query and open man-pages on activation.
This PR add a
plugin_trait
feature which provides a helper trait to write plugins.It reduces the boiler plate needed by wrapping the stdin message passing in a default
run
function, and the stdout messages inrespond_with
.Additionally it implement the same logging behavior the default plugins have.
For a concrete example you can take a look at pop-launcher-mpd