Table of Contents
Design Goals
This project draws heavy inspiration from clay in the way the layout is declared by the user. As terminal applications usually are rendered in intermediate mode, a render loop is also completed at the end of a single event loop. Such that every time an event happens a render call will usually be done as well. However this is not strickly necessary forced by zterm and can be separated to have a fixed rendering of every 16ms (i.e. for 60 fps), etc.
Note
All examples are implemented as intermediate mode rendered applications.
There is only one generic Container which includes properties, child container and optionally an Element. In the end a Container describes a tree structure containing layout and content. Elements describe user defined content and behavior building on top of the existing Container layouting.
The library is designed to be very basic and not to provide any more complex elements such as input fields, drop-down menu's, buttons, etc. Some of them are either easy to implement yourself, specific for you needs or a too complex to be provided by the library effectively. For these use-cases there may be other libraries that build on top of this one to provide the complex elements as some sort of pre-built elements for you to use in your application (or you create them yourself).
Caution
There are no built-in components to provide complex behavior.
There are only very few system events, that are used by the built-in containers and properties accordingly. For you own widgets (i.e. a collection of elements) you can extend the events to include your own events to communicate between elements, effect the control flow and the corresponding generated layouts and much more.
Tip
Keep the tagged type of each user event as small as possible. If you need access to bigger structs you can also always use pointers.
This library also provides a rendering pipeline alongside the event loop implementation. Usually the event loop is waiting blocking and will only cause a re-draw (intermediate mode) after each event - some events usually don't cause a draw (i.e. .init or your own if you want them not to). Even though each frame is regenerated from scratch each render loop, the corresponding application is still pretty performant as the renderer uses a double buffered implementation to only apply the changes from each frame to the next to the screen.
This library is also designed to work accordingly in ssh hosted environments, such that an application created using this library can be accessed directly via ssh. This provides security through the ssh protocol and can defer the synchronization process, as users may access the same running instance. Which is the primary use-case for myself to create this library in the first place.