LIGeR layouts

— the conceptual framework behind the interfaces that may be created by use of the LIGeR method

The essential principle of LIGeR layouts is the division of available space across the main axis between child panes of a parent pane, in turn taking the entirety of its cross-axis size.

This, in essence, has many similarities to a certain configuration of the "flex" display method of HTML, but with several key streamlining features.

More systematically,

A LIGeR layout is a series of nested panes — rectangular objects of adjustable appearance, content and behaviour — laid out in the axis (horizontal or vertical) specified by the parent, whose children request either a fixed or dynamic amount of space across this main axis — the axis of division.

Fixed amounts of space are given in font-height units (referred to in HTML as "em" units) for the purpose of:

  1. allowing for painless construction of text-terminal interfaces (a high priority for the project),
  2. maintaining the complete agnosticity of the layout to preferred font size, resolution and DPI, and
  3. possibly increasing intuitiveness of measurements by referencing desired text contents instead of arbitrary pixel values.

Dynamic amounts of space can take the following values:

  • fit (the default) — used when the pane should calculate the necessary amount of space based on its content. Any of its children with R-based sizes will be drawn as if they were "fit"-sized, too.
  • R (for "Remaining"/"Rest") — to denote that the child carrying this property should take a unit amount of main-axis space after the fixed-size panes had taken their cut.
  • [n]R (for an integer n) — as above, but with an appropriate number of unit-spaces to be taken. This means that a pane with children of sizes R and 2R will be divided into parts of ~33.3% and ~66.7% respectively.

As an example, once a LIGeR surface is created, a layout can be cast upon its root pane thusly,

V:menubar(1em)/addressbar(1em)/body(R)[H:listing(10em)/files(R)]

...yielding a layout whose requirements are fulfilled by an interface such as this:

And after being filled in with the appropriate content, something similar to this: