LIGeR architecture

The construction of the LIGeR framework

In essence, LIGeR is ever-so-slightly like Wayland, in that it's technically a standard, not a specific piece of software. You could write your own LIGeR core that would still "be" LIGeR — in fact, that's all that a port or binding actually is.

A functioning LIGeR stack is described by the following elements, with the ones at the bottom calling and ordering the ones above it:

Complete LIGeR application

LIGeR renderer

LIGeR Core

Your "backend" code

Your code communicates with the Core by using the provided ⛓ API to create and modify layouts, as well as fill them with content and receive input.

The Core parses and validates the layouts and commands, handling the communication with a specific renderer, as well as selecting it in the first place — basing its decision on possible environment variables and more simply which renderers are available to it. Failing to find any externally will cause it to throw a soft warning and use its fallback standard text-terminal renderer.

The renderer's job is to actually calculate and draw the layout. Whether it does that using text in a terminal, SDL3 (the intended "flagship" standard renderer), or even an existing toolkit like GTK, Qt, win32 or anything else, it must obey your layout specification and provide reasonable options for input, as well styling. Theming will be available for both the SDL3 renderer and the text-terminal renderer, in colours, border shapes, margins, paddings and all else that may be desired to be customisable.