Open
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
This PR contains the changes of my plugin-manger's core-patch.
It make two small additions to the core:
src/plugins/plugin_registry.py
Add a single function
register_plugin_blueprints(app)that:get_blueprint(), calls it and registers the returned Flask Blueprint with the appsrc/inkypi.py
register_plugin_blueprintsregister_plugin_blueprints(app)With this plugins are able to register their own routes which opens a lot of possibilities to implement plugins that are not possible without that. (e.g. managing assets, like the pluginManager, remote control and automation with web-hooks and push functionality, admin plugins to interact with other processes or services).
It is a minimal change to the core, adding very little but allowing complex plugins. It is backwards compatible, plugins can just ignore it.
Complexity lives in plugins, not core.
Any “clever” or powerful behavior (REST APIs, webhooks, custom endpoints) is implemented inside the plugin’s Blueprint and its own modules.
Core does not gain new concepts (e.g. “plugin APIs,” “plugin webhooks”) beyond “plugins may register one Blueprint.”
edit
Here is a simple poc plugin that uses the registration to add a route to force the currently displayed instance to refresh, it is intended to be called, for example by the PiSugar service but it could easily be called by a script monitoring GPIO pins to add other buttons (this could be set by the settings inside the InkyPi UI which is empty for now) or an automation like NodeRed - yes I am aware that this could also be done by creating a script that finds out what's running from device.json and call /display_plugin_instance with the accuired info but this is a much more stable and less hacky way that is usable for users who do not dive in that deep...