[orx-camera] In OrbitalControls, make userInteraction toggleable

[hamoid]

provide enable / disable userInteraction

Currently userInteraction is set up inside OrbitalControls::setup() and it stays the same during its lifetime. It contains 6 calls to .listen():

            program.mouse.moved.listen { mouseMoved(it) }
            program.mouse.buttonDown.listen { mouseButtonDown(it) }
            program.mouse.buttonUp.listen { state = STATE.NONE }
            program.mouse.scrolled.listen { mouseScrolled(it) }
            program.keyboard.keyDown.listen { keyPressed(it) }
            program.keyboard.keyRepeat.listen { keyPressed(it) }

A method in this direction would be needed:

public fun setUserInteraction(enabled: Boolean) {
  // here we either .listen() or .cancel() the listening
}

This method would replace the .listen() calls inside setup(), but also can be called by the user to enable / disable interaction.

For that to be doable Event.kt needs a method for canceling listeners.

Discussion at https://openrndr.slack.com/archives/CEASC1PB7/p1584368959475400

[edwinRNDR]

Another approach would be to check if userInteraction is true inside the keyboard and mouse listeners.

[hamoid]

What would be best if we wanted to control two or more viewports with the mouse? Say drag on one viewport to rotate, then on a second viewport.

[edwinRNDR]

What would be best if we wanted to control two or more viewports with the mouse? Say drag on one viewport to rotate, then on a second viewport.

That's pretty tricky I think. On one hand you have input handling that is tied to where the viewport is placed on the screen, on the other hand you will likely use render targets to implement the rendering so you don't want to use view port offsets there.

I guess you could start by giving OrbitalControls an optional inputArea Rectangle. Then either an additional extension or your application directly takes care of positioning the rendering results and recalculating the inputAreas