Skip to content

Input system design

Alexandre Bury edited this page Jul 8, 2018 · 2 revisions

Requirements:

  • After receiving an input that causes Cursive::quit(), we should not consume any more input.
    • This means before consuming any input, we should make sure the previous input did not stop the event loop.
  • Support callback pre-emption: Cursive must be able to react to callbacks sent from other threads while still waiting for input.
    • For blocking input, this means the hanging input has to be running in parallel with the output reacting to callbacks. This means the backend must be somewhat thread-safe.
  • Batch input processing: Cursive must be able to process multiple pending events without re-drawing the screen.
    • Combined with the first requirement, this means each input from the batch must be processed before the next one can be consumed.

A solution to satisfy that is composed of 2 channels:

  • Input Requests, from Cursive to the backend, notify the backend that it's safe to consume an input.
  • Event channel, from the backend to cursive, transmits the event as they arrive.
Clone this wiki locally