You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I'm the owner of the Continuous Print plugin for OctoPrint and an avid user of Kiri:Moto for slicing and spooling files. My plugin automatically adds uploaded files to a print queue, which is triggered by listening to the UPLOAD event that fires when a file is uploaded via the REST API. All "typical" file upload paths (drag & drop, clicking the Upload button, API call from e.g. PrusaSlicer) go through the REST API in this way.
However, the GridSpace plugin uses self._file_manager.add_file, which bypasses the API and doesn't fire this event. FILE_ADDED does fire transitively due to adding the file, but this event is too generic - it also happens whenever a file is copied or moved, so is not sufficient for detecting when a new gcode file is added with the likely intent for it to be printed.
I'd like to contribute a PR to increase compatibility with other plugins that want to perform actions when KM spools new files. What do you think about one of these options:
Spoof an Events.UPLOAD event firing when a spooled file is saved, basically copying from here. This would maximize compatibility with other plugins, but is a bit sneaky and may bitrot if there are changes to OctoPrint's use of the UPLOAD event.
Create and fire a custom KIRI_MOTO_FILE_UPLOAD event. This adds more boilerplate to the GridSpace plugin and requires individual plugins to integrate specifically with the GridSpace plugin to receive the event, but gives you full control over the event life cycle.
Make a web request to the REST API to upload the file after it's spooled to disk (rather than using filemanager.add_file). This seems really redundant/clunky and I'd prefer not to go this route.
Thanks in advance!
The text was updated successfully, but these errors were encountered:
Hi @smartin015 and sorry for missing this earlier. I think option (1) is likely the fastest way to go here. If you want to submit a new PR, I'll push it out with the release this weekend.
I'm the owner of the Continuous Print plugin for OctoPrint and an avid user of Kiri:Moto for slicing and spooling files. My plugin automatically adds uploaded files to a print queue, which is triggered by listening to the UPLOAD event that fires when a file is uploaded via the REST API. All "typical" file upload paths (drag & drop, clicking the Upload button, API call from e.g. PrusaSlicer) go through the REST API in this way.
However, the GridSpace plugin uses
self._file_manager.add_file
, which bypasses the API and doesn't fire this event.FILE_ADDED
does fire transitively due to adding the file, but this event is too generic - it also happens whenever a file is copied or moved, so is not sufficient for detecting when a new gcode file is added with the likely intent for it to be printed.I'd like to contribute a PR to increase compatibility with other plugins that want to perform actions when KM spools new files. What do you think about one of these options:
Events.UPLOAD
event firing when a spooled file is saved, basically copying from here. This would maximize compatibility with other plugins, but is a bit sneaky and may bitrot if there are changes to OctoPrint's use of the UPLOAD event.KIRI_MOTO_FILE_UPLOAD
event. This adds more boilerplate to the GridSpace plugin and requires individual plugins to integrate specifically with the GridSpace plugin to receive the event, but gives you full control over the event life cycle.filemanager.add_file
). This seems really redundant/clunky and I'd prefer not to go this route.Thanks in advance!
The text was updated successfully, but these errors were encountered: