Allow multiple Remote Print events from RoboPaint HTTP API

[oskay]

Currently, only a single painting (or drawing) can be made from the high-level RoboPaint API without manually resetting the status through the GUI. For many applications including automated production of animations, it would be much nicer to have the option to NOT require a manual reset before every painting.

I would propose to add a second checkbox (checked by default) in the settings:

[ X] Exit remote print mode when printing finishes
If checked, RoboPaint will exit Remote Print mode when your print finishes, so that it won't start another drawing or painting before you have time to swap out the paper.

If it is unchecked, then Remote Print mode should remain persistently on, so long as it is checked in the title bar. We should also change the text displayed when entering remote print mode to read:

If "Exit remote print mode when printing finishes" is checked in the settings, then this mode will exit when once an image is finished.

[techninja]

Personally I'm curious as to what physical situation the WCB could be in that it can draw the next image in the queue immediately without needing operator intervention... but more importantly:

New paradigm: As part of #227, SVG verification has been.. tossed out the window, but really it was the only thing holding this back. (Shouldn't it be up to the client to make sure it's not flinging bad SVGs to us? I mean really!)

Without verification, as soon as RP is running, it can start taking items into the queue, and only upon entering Remote Print mode and clicking the "Ready" button (not sure on wording), will it start processing the queue, printing out the current image in the queue, then waiting for the next ready signal to rinse/repeat.

If I understand correctly for this issue, then all we need is a checkbox like:

• "Don't require operator interaction before processing the next item in queue"

Then once it finishes with one, it'll skip right over to the next one. Of course as the operator you'll still have pause and other buttons available which should reflect in remote queue status.

[techninja]

Yea, OK, I think I have this managed. You'll have to test. I'll see if I can't make a new test build this week.

[oskay]

Physical situation No. 1:
You are using a painting program that generates SVG and automatically sends the SVG to the WCB. You are sitting in front of the computer and WCB, to change out the paper and check supply levels constantly. Everything works fine except that after every single print has finished, you also for no apparent reason have to change context, go into RoboPaint and tell it that no, you haven't changed your mind, and yes, you still want to remote print.

If that context were that you were doing a "finger painting" demo at a museum, this would be an absolute deal breaker-- having to change context and tell it to re-enable remote printing.

Physical situation No. 2:
You are painting watercolor animations, with a continuous scroll of paper. After each painting finishes, the overall control program scrolls the paper to the next frame. It would be able to operate on its own for hours (until the paint/water levels run low), but instead a human (or perhaps macro scripting software) has to go into RoboPaint and tell it that yes, you still want to remote paint, after every frame.

Alternative approach:
Rather than using a checkbox in the settings, an alternative approach would be to have a API command (or, argument to existing commands) that keeps the port open after the current painting finishes.

[techninja]

Very good to have these use cases defined! I believe what I've built is actually inappropriate for both as it provides basically zero time between images, but in general it's far easier as it doesn't have to change any mode or leave any context, images are just sent in whenever then as long as "Ready" is checked in the mode, they start printing.

Adding an API command for readying the operator status/bot is a great middleground as it allows the client application to choose when to trigger it. I'll add it next I get the chance.

[oskay]

I think that I now understand where you were coming from: The human-interaction element was (in your view) providing a necessary limit to the painting of multiple queued* images, where I was imagining use cases that were already externally rate-limited by human or machine interaction. So adding a "Ready to print!" API command would definitely be a good middle ground.

*bonus word score: four vowels in a row

[techninja]

Ahh, human limited queueing*! That makes perfect sense for the no-reset state then, AND if clients get picky or there need to be more items in the queue, the ready state can be externally handled and will work hand-in hand with the automatically reset ready state, as the client just has to flip the ready state before (or after) sending the next SVG, no human app interaction required.

*Double bonus word score: five vowels in a row

[oskay]

Did the API option for telling RoboPaint that it is ready to paint ever get added (in which case-- it should be added to the docs) or not (in which case I should open an issue about it)?

[techninja]

I believe the docs may have taken a back seat a bit. If you don't see it in there, open a new one and I'll close with the fixing commit :)