What follows is an overview and definition of the data structures and systems that underpin LIGeR, in order categorical.
The LIGeR Core — the mediation layer between your code and the remaining LIGeR stack; Usually, a library or equivalent concept for a given language, that provides functions that allow for LIGeR actions to be performed by your program. It may also be an executable that can be called with arguments, to be placed in the system's PATH for use by a script, for instance. Its main objective is to determine the appropriate Renderer and communicate with it.
The Renderer — an executable which receives commands from your code via the Core and uses them to create the desired user interface by any method that can satisfy the requirements of the specification. It must also report back the necessary "environment information" back to the Core, and thus your code, so that decisions can be taken based on, for instance, how big the surface is, or whether there are full graphics capabilities or only text. The common "fallback" renderer uses the text-terminal to render interfaces, but the default "flagship" renderer makes use of SDL3, enabling usage on many common platforms.
The Network Transparentisation Layer — an executable which allows for a standard LIGeR application on a remote machine to tap into the top half of the LIGeR stack on the local machine. The prototypical example would be a program interactionally analogous to Waypipe, in that it wraps an ssh command (usage: waypipe ssh [address]), with the effect in the case of the NTL being that any LIGeR Cores will be instructed to exchange their information with the standard input and output stream, which then is captured by the NTL and not displayed in the terminal, instead normally calling the local machine's preferred renderer. In this way: 1) only very low-volume plaintext data is transferred over the network, 2) the application always obeys the local machine's styling and theming rules, and 3) it enables for universally compatible remote application usage not only on Wayland, between X and Wayland, but even between completely unrelated operating systems, e.g. FreeBSD remote machine, Windows local machine.
Layout — possibly the most critical concept in this entire operation. A Layout is a graph data structure that describes the parent-child relationships and the properties of the panes contained within it. It is, in a way, topologically analogous to an HTML file.
Pane — a conceptually rectangular object that has five essential properties:
A pane can contain several different types of contents, most important among them being a set of other panes. When defining this — which also applies to the definition of the first panes in a Layout — you need to select either Horizontal or Vertical alignment: whether you want the child panes to be laid out as columns side-by-side, or rows one above the next. This is referred to as the division axis or the main axis.
A pane's name can be an arbitrary string of letters (uppercase or lowercase), digits, hyphens and underscores. It's analogous to a "class" in HTML — it's the handle by which a pane can be grabbed, so to speak. Modifications to a pane's properties can be made by referring to its name, i.e. changing its parent (rerooting the pane), class or contents. This also means that giving the same name to multiple panes will cause all of them to receive the same modifications.
A pane's size, can take three classes of value:
A pane's class is not analogous to a class in HTML. It's instead more closely related to the concept of a tag itself, in that it has a specific function and associated styles. More specifically, a class is a high level-of-abstraction set of expectations for the pane. For instance:
Each of these has specific implications for its interaction surface and its ability (or lack thereof) to carry children. For instance, text inputs, menu "positions" and buttons can all carry text as their contents (which in the case of text inputs is the default contents of the field before the user edits it), but while menu positions can carry child panes (for instance, for selecting a submenu of a menu), text inputs cannot.
These pages have been simplified in their construction in order to maximise compatibility, including compatibility terminal browsers. Tested with Lynx.