Plugin system redesign

[donadigo]

Currently Scratch in it's plugin interface exposes a few methods that "hook" it's widgets which can then be processed by the plugin in order to add additional functionality to e.g: HeaderBar, sidebar or the bottom bar.

While this works with current set of plugins, it will get harder and harder to introduce new ones that further improve the experience. An example of this would be the Outline plugin; for Vala it displays the symbol structure in the current opened document. There is the problem though, what if we want to also have Vala autocompletion? We probably need to create another plugin just for this, but we end up with two Vala compilers processing the same exact document that's opened both for completion and symbol visiting.

As a proposal, Scratch should expose those widgets, but in a different manner. Hooking widgets should be optional, and instead Scratch should expose and implement a set of different interfaces for common code functionalities like e.g: autocompletion, file manager and others. Currently those widgets are provided by the plugins themselves and there is no way to communicate between plugins. "Vala" or "C" should be one plugin that provides all the functionality that belongs to this language.

---

Want to back this issue? Post a bounty on it! We accept bounties via Bountysource.

[matzipan]

So the issue here is that you want to have shared code between the plugins? I don't know if redesigning anything is entirely necessary here. We might get away with other simpler code refactors.

[jeremypw]

Part of this should be taking as many plugins as possible into the main code. I assume the main advantage of a plugin system is to permit third-party add-ons but I am not aware of any in practice and I do not think they are supported in AppCenter?

[danirabbit]

Yeah I'm personally of the opinion that we should phase out the plug-in system completely. We don't currently have any system for distributing third party plugins like you said, and so far it seems like the plug-in in system is just making it harder to maintain

[Marukesu]

thinking about integration with language environments, an plugin system can be desirable.

[jeremypw]

The existing system will not work with 3rd party plugins once Code has been Flatpaked without a hole in the sandbox? Is there a better way to integrate with language environments in a Flatpak?

[Marukesu]

The existing system will not work with 3rd party plugins once Code has been Flatpaked without a hole in the sandbox?

We can add a extension point to the flatpak, so that the sandbox can be extended as necessary by the plugin.

Of course, things are more complex when we think about searching headers and external libraries, but there's nothing similar to this currently in code.

Is there a better way to integrate with language environments in a Flatpak?

Not that i can think of, apart from flatpak extensions, we would need, either, have all plugins begin build with code, or a weak sandbox.