Laidout Development

Here is some general information about the development of Laidout. As with any project, testers and coders are certainly encouraged to test and code!

Some general links which might be relevant:

Laidout on Github
The Roadmap
Roadmap from the trenches

Bugs and Feature Requests

If there is something that you think is a bug, irritation, or missing feature, you can post an issue on Laidout's github, or search the help page for mention of it.

Development Source Code

Laidout has so far been coded by one person, Tom Lechner, along with a few patches and a translation submitted by various people. It would be pleasant if more people were involved!

Laidout is built on the Laxkit, whose sole purpose for existence at the moment is to be the windowing backbone of Laidout. Anything said about Laidout applies just as much to the Laxkit.

There is copius doxygen style source code documentation for you to whet your appetite, which is easily accessible by running "make docs", which basically just tells doxygen to do its thing. Running "make alldocs" will build all the documentation for Laidout and for the Laxkit, as long as you have a link in the top Laidout directory pointing to wherever you have the Laxkit source files. For release tarballs, the Laxkit is there already.

You can download the cutting edge, latest and (ideally) greatest version of Laidout from the git repository with this command:

git clone

Compiling the Development Source Code

Compiling directly from the dev source has a couple more steps then compiling a normal release. It is assumed that those compiling from dev source like pain. In a nut shell, you must install dependencies, download Laidout source, download Laxkit source, configure, compile, then make the icons.


Any translations done for either messages in Laidout itself, or of the Laidout web pages are greatly appreciated.

Translating Laidout to new languages is mainly a matter of translators translating a couple thousand little words and phrases from a file called laidout.pot. Normally, you take that file, rename it to es.po (a spanish translation, for example), and then update all the strings in it. You can do this by hand, or you might use a program like Lokalize or poedit.

Once translated, the whatever.po needs to end up in the src/po directory of the Laidout source code. There is a README file in that directory with a lot more of the nitty gritty details for dealing with translation files, such as how to merge a new translation with an old one.

Current Translations (french and spanish translations getting very out of date)

The Laidout File Format

Documentation for the Laidout file format is found easily through running:

laidout --file-format

This will dump out a pseudo-Laidout file with copious comments about each of the possible Laidout file elements. The format itself is an indented data file format, sort of in the same spirit of yaml, but is slightly more ad-hoc, making it even easier to read and figure out, in this developer's opinion. Laidout's indented format is simply a collection of nested name-value pairs, where both are scanned in as strings, at which point it is up to the application to decipher the strings into integers, points, and whatnot.

Please click here for the current file format description. If you do not find it explanatory enough, or it is flat out wrong, please let me know..