feat: add 'plugin_trait' feature to pop-launcher-toolkit

[oknozor]

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 in respond_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

[mmstick]

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.

[oknozor]

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.

[mmstick]

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.

[oknozor]

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.

[mmstick]

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.

[oknozor]

Just added a simple plugin example that run whatis on the input query and open man-pages on activation.

[jacobgkau]

launcher-pr113-jammy.txt