This will only style them in a special way and influence sorting. Plugins still need
to ensure that a step is not skipped through the use of the onWizardTabChange callback
in the view model.
"Hello" command sent to printer to trigger initial handshake can now be
configured. Commands that _always_ necessitate to be sent with checksum/
line number (e.g. M110 on Marlin) can be configured as such too.
Also fixed an issue causing the "Hello" command to not be actually enqueued
first thing on opening a connection. Seems to not have caused harm in the
wild, but was unintentional.
Introduced three new events:
* CONNECTING - fired just before starting the connection process
* DISCONNECTING - fired just before starting the (active) disconnection
process
* PRINTER_STATE_CHANGED - fired every time the printer state changes
Also introduced new GCODE script beforePrinterDisconnected, which will
get sent just before the printer gets (actively) disconnected. Also enabled
communication object to wait for the send queue to be emptied before
closing it, in order to allow sending all lines from the disconnect script.
That way plugins don't need to implement the SettingsPlugin mixin in order to access their data folder, which is now an injected property in OctoPrintPlugin. Plugin authors should still always use the getter since that will also make sure the folder actually does exist (lazy creation).
PluginSettings.get_plugin_data_folder has been marked as deprecated.
Added phase specific hooks for queuing, queued, sending and sent phases of a command ("octoprint.comm.protocol.gcode.<phase>"). Removed old queuing phase hook and declared as obsolete hook in plugin manager to prevent plugins that depend on it from being enabled.
Adding those new hooks also necessitated refactoring the whole command processing, made it more modular and added phase specific handler functions that allow handling all blocking commands centrally for example.
This will hopefully prevent conflicting routes between multiple plugins from being registered and also ensures a more consistent behaviour compared to BlueprintPlugin mixins.
Thanks to @Salandora for bringing this up.
The new hook allows extending the list of rules for maximum body sizes differing from the default of 100KB and can be used by plugins to allow uploads to them that exceed that file size.
Also extended the plugin manager to detect plugins that implement restart needing hooks (such as the above one) and handling those plugins the same as plugins containing implementations that inherit from octoprint.plugin.core.RestartNeedingPlugin
Any unknown commands should just be piped through and not use up an acknowledgement. This
new behaviour can be overridden via the new feature flag "unknownCommandsNeedAck", which will
restore the former behaviour causing even unknown commands to use up an "ok".
Also no line numbering or checksumming will happen. Shouldn't usually be of relevance for other
firmwares, but in case of any compatibility issues introduced by this also added a new feature
flag "sendChecksumWithNonGcode" that causes even unknown commands to be sent with a
checksum if necessary.
Repetier always first sends the ok and then any command output. In case of M105, that makes the response look like from an externally triggered heatup (no ok on the same line), causing polling to stop until that falsely detected heatup is complete. Added a configuration option to disable heatup detection. The disadvantage of this is that when printing via Repetier Firmware from SD, the heatup times won't be substractable from the total print time, leading to a less accurate print time left estimation.
Closes#835
* Renamed userjson to userdata, removed original userdata (developers will live if they need to ensure their supplied userdata is valid JSON)
* Input validation for userdata parameter - a HTTP 400 response will be generated if userdata can't be parsed as JSON
* Adjusted documentation accordingly
* moved virtual printer into plugin
* made default serial factory use supplied parameters instead of directly utilizing self._port and similar
* documented new hook
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.
Added a lot of documentation, more stream lining, should now work completely without having to define types but offer the same/more functionality than before. Backwards compatible too.
- 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
Changed some endpoints again (removed "/control" path element) and made API spit out only raw data (e.g. seconds, millimeters, unix timestamps etc) instead of formatted versions. Modified frontend to take care of formatting this data itself.
This WILL break existing API clients and probably some event handlers too. I'm sorry for the disruptive changes, but I needed to rectify some decisions before they went too far utilized elsewhere to still be corrected.
Basically this change completely removes the old API and switches it (same endpoint) with the new one, that's basically the existing AJAX API that the client uses, but way more RESTful and based on JSON (exception being the file upload).
The event system has been revamped to carry more payload data (and in an extensible form as dictionary, to allow for later addition of attributes to single events), with the existing event listeners adjusted to also allow users to make use of this data in their consumers.
Documentation has been greatly enhanced for the REST API (and is still being added to), the events will be documented here as well.
