Brilliant. Now all I need is a Cura plugin that will—with an added button—just do that to a temp folder locally, upload that to a folder on the Pi, rename/uncompress that and then drop/rename the preview file into another folder.
Is there a template-y Cura plugin tutorial somewhere? I guess I should just go to school on your own connection plugin.
This is going rather off-topic, but wouldn't it make a lot more sense to write an OctoPrint plugin that accepts and unzips .ufp files? If you do, I'll make sure they are supported in the OctoPrint Connection plugin.
For the average-use case, yes (that would be great). For this particular project I can't have the user trying to initiate a print job via Cura since they haven't yet prep'd the printer (laser sintering).
That sounds like an interesting project. I don't personally use Cura but could probably throw something together for that. Now I need to download Cura I guess. What version should I use to create a ufp file?
Any version starting from Cura 3.3 can create .ufp files, but I would just go with the current version (4.2.1).
did you stop development of your 3D preview plugin ?
It would be good if you can implement a 3D print preview like simplify 3D
Pretty much. I don't have the time to get into the complexity of webgl. That plugin was basically just enabling the parts that were left out from the original gcode.ws library used for the gcode viewer tab to enable the 3d view.
So I've been able to put together a rudimentary plugin that is able to extract the thumbnail and gcode file from a ufp, just have to figure out if there is a way to override the filename in the preprocessor hook or if I'll have to change it over to using the StorageInterface to add the gcode file. As it stands now, the file keeps the original ufp filename but is able to be loaded and theoretically printed from the filelist. It's just not getting analyzed and therefore the additional information expansion arrow doesn't enable. That's where I wanted to put the thumbnail preview as a test. I guess I could add a button that opens a new window with the thumbnail instead.
Can I have a look at what you have now, so I can start supporting it from the Cura OctoPrint Connection plugin?
Just pushed an update to the plugin that hacked the filename issue, and queues the file for analysis. Adds a button to the file list items that opens a modal thumbnail viewer of the uploaded png file as part of the ufp package.
Wow. I think I would have tried a different route but it looks like you've gotten some traction on that. Guess I'll have to take a look at what you've done. 
What would you have done differently? Always looking to improve my thought logic/ programming work flows.
I'm guessing that you've faked out OctoPrint to allow it to receive UFP files... then uncompressed the package and it looks like you're keeping the original file. (I haven't dived into your code yet.)
I think I would have done something to bring the file over (but not into the ~/.octoprint/uploads folder itself. I'd have then grabbed the gcode out of there, renamed/moved it to the watch folder and then to have renamed/moved the samename.png into maybe ~/.octoprint/uploads/.preview perhaps. I'd have then deleted the UFP file completely when this process is complete.
I would call mine an "over the transom" approach whereas yours uses the more directed path.
You are correct in your assumptions, I'm using all built in mixin implementation and octoprint hook methods. This allows octoprint to support the file upload of ufp files, then uses the preprocessor hook to save the uploaded file to the plugin's data folder and extracts the preview image into the plugin's data folder as well as the gcode file renaming it to match the original ufp filename. The preprocessor hook then just returns a handle on the gcode file, which then continues the standard octoprint process for saving to the uploaded location. This was all well and good, but maintained the original ufp file name and therefore the gcode analysis wasn't running on it. You could have still printed it, but in order to get analysis I used the on FileAdded event to rename the file to gcode extension. I guess I could have just extracted the gcode file directly to the watched folder like you mentioned, but the preprocessor hook throws upload errors if you don't return a file wrapper object at all and then you'd be stuck with a ufp file in your file list. The plugin could easily be modified to remove the ufp file during the preprocessor routine, and I'll probably incorporate that as I'm currently deleting all those files on gcode removal.
I suppose that's why I was thinking that I needed to get past the ~/.octoprint/uploads folder directly because I didn't want it trying to analyze that file directly and I wasn't actually interested in the file itself, just its contents.
See what you can do with it and I'll give it a spin next week, I guess.
I don't think you understand what it is doing. It's not analyzing that ufp file directly, but the gcode file that I'm handing it as part of the preprocessor hook, which is extracted from the uploaded ufp file. Basically I'm doing exactly like you suggested except I'm not deleting the ufp file automatically as part of the upload process, but that file is stored inside the plugin's data folder, not in the uploads folder so it's not analyzed. And instead of the thumbnail being extracted into a hidden uploads sub-folder (your .preview example) I'm saving it into the plugin's data folder and using route hooks to make the plugin's data folder web accessible.
I am working on a version of the OctoPrint Connection plugin for Cura that works with the UltimakerPackageFormat plugin:
I would like to be able to easily detect the plugin from my side. The easiest way to do so is if the plugin has a preference (any preference, really), so it shows up in the api/settings endpoint.
One remaining issue is that prints currently cannot be started (or selected) automatically after uploading, because the file that is uploaded is not the gcode file that should be sent to the printer. I'm not decided if this should be fixed on the Cura side or on the OctoPrint side.
Ohhh... alright. I think I've got it now. Yeah, that's probably the way to go.
When you say preference, you mean a setting? I included the settings mixin just am not currently returning anything in it. I just added a installed=True setting to the plugin and pushed an update to version 0.0.4.
