Many widgets and layout managers have explicit locks that block all other execution threads from accessing the widget. LibCXX Widget Toolkit maintains its own internal execution thread that, amongst other things, updates all windows and widgets.

The need for explicit locking is obvious. This allows working with the contents and the state of a particular widget without having it simultaneously modified as a result of some input activity. LibCXX Widget Toolkit's internal execution thread might access any widget at any time, for example to redraw its contents if the display server does not use backing stores and sends an exposure event because some other application's window moved.

Constructing locks in dynamic or static scope should be avoided. It's always better to construct locks in automatic scope.

A container's get_layoutmanager() constructs and returns the container's layout manager. Layout managers holds their own internal locks on their container, to have a consistent snapshot of the container's contents while the layout manager makes changes to it.

Like locks, layout manager objects should not be stored in dynamic or static scope. Layout managers' locks are much broader in scope, and affect the entire container. A layout manager object should get instantiated on as-needed basis, with get_layoutmanager(); and kept in automatic scope so that it gets destroyed when no longer needed.