Multiple mixins are allowed of course. Allowing multiple implementations lead to too many problems due to plugin names for referring to the APIs of SimpleApiPlugins or the assets of AssetPlugins.
Hence __plugin_implementations__ has been deprecated in favor of __plugin_implementation__. The plugin subsystem will automatically copy the first implementation from __plugin_implementations__ to __plugin_implementation__ and log a deprecation warning.
Adjusted documentation accordingly. Also added docs for helpers.
Detected plugins are now logged in a better readable way and with additional information.
Also marked folder for bundled plugins as bundled - forgot to do that earlier.
Preprocessing for better performancy, unit tests for preprocessing, controls don't need a type anymore (makes things way less complicated and repetitive)
Added wrappers to ensure existing plugins being able to work, although them using the old camel case method names now causes a deprecation warning being logged
Should catch any exceptions thrown by the plugin, log them and only hand them off if the caller requested to be informed about such things. This way if something goes wrong with a StartupPlugin there should be no problem anymore to still get the server up and running.
This data can still be overwritten from within the Plugin itself by setting the correponding __plugin_xyz__ variables, however it allows getting rid of some repetition if that data has already been specified in setup.py
get_template_vars get split into get_template_vars (for injection additional template variables only) and get_template_configs (for configuring injection of additional template). It's now possible to inject more than one of a given template type from within plugins, and template injection is more intelligent in that if a plugin's templates don't need special configuration and stick to default naming and behaviour, just declaring them inside the templates directory of the plugin will be enough to fire up everything including links to switch to tabs, sidebars etc (the plugin's name being used in such cases for link text).
In order to solve the initial handshake problem with apps, OctoPrint now supports so called app session keys which are basically API keys with a limited validity. Obtaining those keys is based on a handshake procedure backed by RSA signatures. OctoPrint needs to be aware of apps and their associated public keys (with the AppPlugin there exists a mechanism to add additional recognized apps by installing a plugin). Apps perform the handshake by first requesting a temporary key with very limited validity, then sending a message back to OctoPrint containing their id, version, the temporary key and a signature created with their private key over these three pieces of data. OctoPrint then tries to verify the signature and if successful unlocks the key to be used as a fully recognized API key.
- be able to handle slicers which can't report progress
- distinguish between registered and configured slicers (e.g. to allow uploading of profiles via the settings before having saved the path to the executable)
This way there won't be two concurrent jobs trying to slice to the same file, which would practically render the cpu cycles from any slicing jobs than the final one wasted. Also adds a new event "SlicingCancelled" that will be sent in these cases.
- File management is prepared to support folders (UI still lacking support)
- STL files are now first class citizens
- can be managed via the file list (and filtered from it)
- can be sliced on demand
- Slicing now happens via plugins
- Added Cura plugin
- uses CuraEngine directly instead of full Cura installation
- Cura profile importer for importing profiles from regular Cura installs via settings dialog
- TODO: UI for editing profiles
- API for slicing and slicing profile management
