Recreate Remote Paint as an actual mode

[techninja]

Right now, remote paint is a non-mode. A piece of code that sits in front of RP proper, and controls other modes, providing a non-standard overlay mode. While this is certainly possible to re-implement in the new PaperJS branch, it requires some jiggery-pokery that I don't think we need, and is pretty well against any standards setup by other more "mode"ly things.

All the hard stuff that print mode used to do with some wacky wrappers and shared code with only manual mode, are now clean & open node APIs. We can re-implement all the functionality of auto-print mode, and most of what we needed from method-draw.

Really, this issue is a question: Method draw acted as dual purpose:

1. Make sure the SVG parsed correctly and was simplified enough to be printed
2. Resize the image to fit the canvas.

Without it, Paper.js has a built in "fit to area" functionality, and I think manages error callbacks for bad files, or at least does its best with what it's given. If we're OK with that simplification, then Remote Paint would become a full mode:

• Presenting the user with an empty canvas, and a disabled pause button, and likely the standard three buttons for calibration (unless I get to #213). Also probably an API status area, showing how many items in the queue, waiting on user input, etc.
• It would instate its API only after being loaded as a mode. I'd suspect that we'd also remove the endpoint once the mode is closed. This doesn't quite match spec, but it's very close, as without the Remote print window open before, the API would just return "sorry, can't do that right now"
• Another button that might be nice is a "Ready for next job" state button, when clicked would let the API know that it's ready to process one queue item.
  • Once an item in the queue was done painting, the state of the button would reset, waiting for a user to put paper in and start again. Could even show on the canvas the image that's next.

Whatcha think @oskay ?

[oskay]

Basically, sounds good. Keep in mind #224.

One worry: I like one part of the current setup, which is that to use the API, one needs only open RoboPaint, and have it run in the background. (Say, with Snap integration.)

Requiring the user to manually invoke the "remote" mode would add a layer of unwelcome friction to that process.

[techninja]

It's quite possible to have modes load their APIs in a persistent way (and may be somewhat required), it's just it may require some funny actions to ensure the mode change happens when it needs to. I suspect things may still be cleaner. In this way, so after the current workthrough I'll add it to the list.

Also I may have a few questions on #224.

[techninja]

Okey doke: This be done!

https://github.com/evil-mad/robopaint-mode-remote

You can likely glean a bit from the preview picture in the readme, but suffice to say:

• API it provides is persistent (even outside of entering or even enabling the mode!)
• API always accepts new SVGs to add to the queue unless the API is explicitly turned off... of which there's currently no UI to do so, or any reason.
• Settings overrides work, as do realtime previews and everything else we always wished it had.

Double Bonus: This only took a couple days to write, it's amazing what extreme modularity can buy you in code reuse!

Note: The skeleton for job cancelling is there, but it's not fully fully supported or tested. It'd probably take another day to get perfect, but I'm rushing for getting this to a real release.

[oskay]

Sounds great!

[techninja]

@oskay As yet another reminder, I'll likely need you to test this as you have the 2.0 Beta in your hands. Close if you think it does the job.

[oskay]

Yes. I am at a conference this weekend and won't be able to test until after I'm back in town.

[techninja]

No rush, have fun! :)

[techninja]

@oskay You ever get a chance to test this? Just for the sake of being tidy wanted to close the issue.

[oskay]

Apologies; was on my to-do with this week's beta. I have not tested it yet. I think that we need some kind of rigorous test procedure to make sure that we don't miss any functions or capabilities.

[techninja]

I've set at least SOME of those up for cncserver, but I have yet to figure out the best method for automated testing on basically any part of RP. Best thing of course is that Electron has a bunch of users already working that out, so we should definitely be able to get that moving. I'm imagining a tests folder in the robopaint-mode-remote repo with possibly its own gruntfile for managing it... HRMMmmm

[techninja]

I'm going to take a wild guess and say this has been tested and managed, if there's further issues they can be opened against the project directly or RP here :)