move edn_view into layout

output/README.md

@@ -1,4 +1,6 @@
-# `tek_layout`
+# `tek_output`
+
+## free floating layout primitives
 
 this crate exposes several layout operators
 which work entirely in unsigned coordinates
@@ -39,3 +41,36 @@ are not dependent on rendering framework.
 **todo:**
 * sensible `Margin`/`Padding`
 * `Reduce`
+
+## example rendering loop
+
+the **render thread** continually invokes the
+`Content::render` method of the application
+to redraw the display. it does this efficiently
+by using ratatui's double buffering.
+
+thus, for a type to be a valid application for engine `E`,
+it must implement the trait `Content<E>`, which allows
+it to display content to the engine's output.
+
+the most important thing about the `Content` trait is that
+it composes:
+* you can implement `Content::content` to build
+  `Content`s out of other `Content`s
+* and/or `Content::area` for custom positioning and sizing,
+* and/or `Content::render` for custom rendering
+  within the given `Content`'s area.
+
+the manner of output is determined by the
+`Engine::Output` type, a mutable pointer to which
+is passed to the render method, e.g. in the case of
+the `Tui` engine: `fn render(&self, output: &mut TuiOut)`
+
+you can use `TuiOut::blit` and `TuiOut::place`
+to draw at specified coordinates of the display, and/or
+directly modify the underlying `ratatui::Buffer` at
+`output.buffer`
+
+rendering is intended to work with read-only access
+to the application state. if you really need to update
+values during rendering, use interior mutability.