KMonad.App.Dispatch

The Dispatch component of the app-loop solves the following problem: we might at some point during execution be in the following situation: - We have set our processing to held - There is a timer running that might unhold at any point - We are awaiting a key from the OS

This means we need to be able to: 1. Await events from some kind of rerun buffer 2. Await events from the OS 3. Do both of these things without ever entering a race-condition where we lose an event because both 1. and 2. happen at exactly the same time.

The Dispatch component provides the ability to read events from some IO action while at the same time providing a method to write events into the Dispatch, sending them to the head of the read-queue, while guaranteeing that no events ever get lost.

In the sequencing of components, the Dispatch occurs first, which means that it reads directly from the KeySource. Any component after the Dispatch need not worry about wether an event is being rerun or not, it simply treats all events as equal.

Documentation

The Dispatch environment, describing what values are required to perform the Dispatch operations, and constructors for creating such an environment.

data Dispatch

The Dispatch environment

mkDispatch :: MonadUnliftIO m => m KeyEvent -> ContT r m Dispatch

Create a new Dispatch environment in a ContT environment

The supported Dispatch operations.

pull :: HasLogFunc e => Dispatch -> RIO e KeyEvent

Return the next event, this will return either (in order of precedence): 1. The next item to be rerun 2. A new item read from the OS 3. Pausing until either 1. or 2. triggers

rerun :: HasLogFunc e => Dispatch -> [KeyEvent] -> RIO e ()

Add a list of elements to be rerun.