More powerful plugin API proposal

Plugins API

Looking for feedback on couple of thoughts around ways to improve our plugin API

Reasoning

There’s a lot of requested features for Kap and I know we try to not add new settings/preferences, but it gets hard to manage all of that. I think a good solution is for these features to be plugins. The current plugin API is a bit limiting (only exporting). We should try to expand it a bit more and allow for a bigger variety of plugins, that can take the load off of Kap. This will also help people only have the functionality they want.

I’ve been thinking about a few of these for a while, but I wanted to put it in writing, so I can keep track and get other people’s thoughts on the matter before I start implementing parts

APIs

Exports

This is the only type of plugin we support at the moment. I think the API we currently have is good, but we might experiment with more options, like:

• Allowing plugins to add/modify ffmpeg arguments (use cases: slow motion, speed up)
• Allow plugins to not use the default ffmpeg process we provide but handle the export completely on their own (more complex ffmpeg conversions)
• Allow plugins to provide error messages (we let them provide loading text, should be able to have them show a meaningful error when the export fails)
• Maybe somehow allow export plugins to be connected? As in, Recording -> Reverse plugin -> Slow mo plugin -> Export to GIF
  • For this it might be worth having two types of plugins, one being editing and one being export (editing being mp4 -> mp4, exporting being mp4 -> target)

Recording

The way I’m picturing this is with some hooks (maybe an event emitter) that allows plugins to run code before the recording starts, and after it’s done (maybe separate for error/success). This would allow current built-in features like Hide Desktop Icons/DND/Key Cast/Custom Cursor to be plugins.

Deep Linking

For any type of plugin, I think deep linking is something that might be useful for OAuth with external services. We could have the format of the default url be something like kap://plugin/{pluginName}/some/path and the app is responsible of taking that and sending /some/path to the right plugin.

Implementation-wise, I’m not sure what the best way to do it. OAuth is generally an async process, but the plugin will be probably opening a link to the login page and waiting for a response. So maybe a waitForDeepLink() function that just waits for that deeplink and resolves when it receives it? Or maybe have them define a general deep link callback, which then can take care of writing whatever data it needs (token) to the store async from when the login happened? (either way we can document it)

Settings

It might be worth letting plugins have their own settings UI, if it’s more complicated than plain JSON Schema. Since they can have electron as a peer-dependency, they can create their own window and render their own preferences. Use-case for this is for example, for a possible custom cursor plugin, a UI to let the user select between cursors.

Metadata

• We added a field that plugins can use to define what version of Kap they are compatible with. We might want something similar with what version of Kap Plugin API they are compatible with, unless we keep it 100% backwards compatible with the current API.
• Having a plugin type (editing/export/recording) might be useful to filter/separate them somehow in the preferences window

Changes to current API

I don’t think I’ve seen any plugin export more than one of what we call services. It sounds like it would allow one npm module add two different plugins (maybe related), but I haven’t seen a use-case for it yet. I think it might simplify both the developing of plugins and the code for reading them if we assumed each module only exports one plugin, with one set of settings.

Other Thoughts

I’m still trying to figure out how linking multiple “editing” plugins could work UI-wise, or if that’s something we consider out of scope for Kap, even when it’s implemented through plugins, since it’s a screen recorder, not really an editor. We provide some editing (size/fps/cropping), that are all supported through ffmpeg commands. So maybe supporting plugins adding/modifying ffmpeg arguments is enough?

[karaggeorge]

@sindresorhus I think all of the comments here were implemented in those last few PRs. I think we can close this and open new issues for anything else that comes up?

[sindresorhus]

For example a gif conversion has 2 ffmpeg calls, so I’m not sure how we would allow for ffmpeg arguments to be edited with the first idea. Also for example when I was trying to get the alternate cursor with the original method (generating a video of just the cursor and overlapping) that also needed two ffmpeg calls, before the actual final conversion one (one to generate the transparent video and one to overlay them).

Maybe we just give them access to what arguments we use and also the ffmpeg instance and let them do their thing however they like. Then they can choose to use the arguments we use for each call, tweak them, or use their own.

Would they export a react component? And would that overwrite our default UI, or would it extend it (include it at the top/bottom)

Export React component, yes. It would extend. Probably top, but could also be configurable, I guess.

But how could we tell the type? I guess an export one would have the export action, recording would have hooks, and editing would have ffmpeg calls? As in, are we determining the type from the type of keys in the service?

I assume each service would have a separate export:

exports.shareServices = […];
exports.editingServices = […];
exports.recordingServices = […];

So we just check the length of those arrays.