Why we extracted Desk Engine

SouthpawStrings puts several practice tools on one desk. A player can move, resize, minimise, and reopen their windows, and keep the arrangement they want. Making all of that behave the same way every time turned into a large piece of software in its own right.

Desk Engine takes that window behaviour out of the guitar site so other applications can use it too. A fix to window layout can then be made once, in the library. Each application picks it up by updating to the new version.

What the engine does

The engine handles where windows sit and how big they are. It arranges them so they fit without overlapping, and snaps them into place near edges. It also handles keyboard control and undo. When a saved layout loads, the engine checks it and repairs anything broken. It does not need to know what a guitar scale is, or what is in an engineering task.

Each application that uses the engine supplies a list of its own apps and how large each one may be. It also supplies the rules for its own shared settings. So knowledge about the product stays in the application, while every application gets the same window behaviour.

The core is plain TypeScript and does not depend on any user-interface framework. Applications built with React, a popular framework, can add an optional part that provides ready-made window frames, controls, and helpers. Keeping the two apart lets the React part grow without forcing React on anyone who only needs the core.

How the extraction was approached

The first step moved the existing code for layout, snapping, keyboard control, undo, and saved state into the library, together with its tests. SouthpawStrings kept small compatibility layers, so saved desks and existing code did not all have to change at once.

Later releases added shared window controls, sections that fold away, and dragging. They also keep windows inside the visible screen, and let you move between windows by direction from the keyboard. Each application still updates on its own. Publishing a new version of the library does not mean every application has adopted and tested it.

Several details protect people's saved layouts. If a saved layout is broken, the engine falls back to safe defaults. A window that sizes itself to its content does not get stuck at an old height. When an app is renamed, the engine must be told its old name, so a saved window that used that name is not quietly lost.

Scope and limits

The engine and the applications that use it are released separately. A change to the engine reaches an application only when that application updates to the new version and tests it.

Continue reading

Read the case study for how the library was pulled out, or just look around. If you are reading this in a window, that window runs on it.

This is a reviewed public summary, not the full project documentation. The live systems, source code, admin tools, operating instructions, and release records are private. Access details and other private operational information are not published. How I Build explains where that line sits.