Plugin API

[Mai-Lapyst]

This PR contains a first design and POC of a plugin API for PrismLauncher; related to #1240.

The current draft implements a few things:

• configuration for a plugin directory
• discovering & loading of plugin metadata in said directory + an basic UI in the launcher settings to manage plugins.
• "contribution" based data-driven plugins
• optional ability for plugins to specify native qt plugins
• adding a extension point for plugins to provide cat packs as an basic example

To test things out i've created a test plugin over here: https://github.com/Mai-Lapyst/prism-test-plugin

The design

The basic idea behind this version of a plugin API is to make plugins as much as possible data driven. Here's an example plugin.json:

{
	// Basic metadata about the plugin; primarily used in the management UI
	"formatVersion": 1,
	"displayName": "Test plugin",
	"description": "A plugin that adds a catpack for test purposes",
	"homepage": "https://github.com/Mai-Lapyst/prism-test-plugin",
	"issues": "https://github.com/Mai-Lapyst/prism-test-plugin/issues",
	"icon": "./icon.png",
	"license": "GPL-3.0-only",
	"authors": [
		"Mai-Lapyst"
	],

	// Metadata about the files providing the native part of an plugin
	// This section is optional and if no contribution requires this
	// it ideally should neither be provided by plugins nor used
	// by the launcher (currently WIP)
	"natives": {
		"osx": "",
		"win32": "",
		"win64": "",
		"linux32": "",
		"linux64": "./libtestplugin.so"
	},

	// This section describes in a data-driven manner, what the plugin
	// wants to do / provide to the launcher.
	"contributions": {
		// Plugin contributes one or more cat packs; entries are simply
		// paths to an (json) cat pack as already defined in Prism.
		"cat_packs": [
			"./cats/my_cute_cat"
		]
	}
}

A data driven approach was picked to reduce developer burden for writing a complete C++ native plugin, compiling it for every platform (OS + Processor) only to do basic tasks. This also prevents bugs where plugins might not register / deregister everything correctly and thus become not completly unloadable without a restart (currently WIP). This also minimalizes entrypoints for malicious code an thus improving security for simple plugins.

The next steps

To further extend the API, there is unfortunatly a rather large set of edits needed to the core structure of the launcher. For example: modplatforms all extend a basic page but it would be against the data driven approach to requiring every plugin that wants to add a modplatform to implement it themself, potentially breaking the UI/UX design of the launcher too. Loaders are completly NOT extensible since it's internally represented trough a compile-time enum.

To further work on this, it needs to be decided how these and similar issues are solved, and if this should be done in this PR, making it potentially VERY huge, or to do it incrementally by reworking the internals with each plugin extension point added.

[TheKodeToad]

😍 very cool - thank you for spending time on this!

[TheKodeToad]

Loaders are completly NOT extensible since it's internally represented trough a compile-time enum.

Hmm, that's hard. One thing that's unique to every loader (which are components) is a UID (usually reversed domain), so a QSet of component IDs could be a (less efficient) replacement. In future there may be a way to add loaders to menus without plugins (I think a repository system would be better) - I don't think you should need a plugin to register a new loader type if you went with that sort of system.

To further work on this, it needs to be decided how these and similar issues are solved, and if this should be done in this PR, making it potentially VERY huge, or to do it incrementally by reworking the internals with each plugin extension point added.

Yeah... probably best to have separate PRs to avoid a lot of merge conflicts

[Mai-Lapyst]

Loaders are completly NOT extensible since it's internally represented trough a compile-time enum.

Hmm, that's hard. One thing that's unique to every loader (which are components) is a UID (usually reversed domain), so a QSet of component IDs could be a (less efficient) replacement. In future there may be a way to add loaders to menus without plugins (I think a repository system would be better) - I don't think you should need a plugin to register a new loader type if you went with that sort of system.

While it's true that a (native) plugin might be a overhead, I still would like to add the ability for a plugin to add an loader type, so developers can reduce the steps for someone to install their stuff to a simple plugin install, which then configures / adds all the things neccessary.

To further work on this, it needs to be decided how these and similar issues are solved, and if this should be done in this PR, making it potentially VERY huge, or to do it incrementally by reworking the internals with each plugin extension point added.

Yeah... probably best to have separate PRs to avoid a lot of merge conflicts

Okay; will then polish this PR, maybe add a thing or two, and make it into a normal one so it can be reviewed properly and merged.

[DioEgizio]

A first thing I noticed is that you put Win32 and win64 in natives but we also have an arm build and it should make the distinction between mingw and msvc too and for macOS It also needs both x64 and arm64

[Mai-Lapyst]

A first thing I noticed is that you put Win32 and win64 in natives but we also have an arm build and it should make the distinction between mingw and msvc too and for macOS It also needs both x64 and arm64

Hmm is mingw and msvc that incompatible? I would like to keep down plugin-dev's burden and not require them to compile things more times than strictly neccessary.

It's generally a problem currently: since PrismLauncher is distributed twice, once with Qt5 and once with Qt6, it would be needed to compile the plugin once for each qt version, and that is without any custom rendering hook's or similar.

Because of that it might be a better way to map out what plugins should be able to accomplish. I.e. should we allow them to create their own ui elements, can we get away with ui custimisation by a declarative approach and only require a native library for API requests or file handling and so on.

[DioEgizio]

Note that we don't have a x32/qt5 build anymore on windows and we're probably gonna drop qt5 soon-ish