It's likely that your application has requirements that are different to standard layouts or more complicated than the toolkit's API supports. Using standard layouts where possible is recommended but that doesn't have to mean giving up on your ideal application design. Every toolkit supports custom layouts in some manner that you can make use of to fill the gaps in the available standard layouts. When implementing a custom layout in this manner, the basic approach is to set a fixed position for each component within the parent container. To better adapt to the available screen space, remember to factor in the current width and height of the interface; it's often easier to implement using ratios or percentages rather than absolute values (for example, a list component is 25% of the screen width or content columns are 1/3 of the available space).

In more advanced toolkits, there's also a constraints-based layout available, one that lays out components based on configured equations instead of hardcode values. The standard algorithm for constraints layouts is named Cassowary and is fully documented at http://overconstrained.io/. The basic principle is that each layout value can be defined as the result of an equation in the form item1.attr1 = item2.attr2 × multiplier + constant (such as button.top = content.bottom × 1.0 + 25). Constraints-based layouts (also known as auto layouts) are standard in iOS and Android but not so common in desktop toolkits. Modern GUIs often include this functionality as standard but using this functionality in others such as Qt and GTK will require the integration of third-party projects (as these aren't currently available through Go bindings, the integration is out of scope for this chapter):