The general idea of the widget system is to be lean, yet flexible. We do not want to provide as many widgets with as many options as a full blown GUI toolkit, But at the same time, we want to be able to adapt the GUIs style to what fits best to a specific game. To achieve these goals, the implementation is split into a logic and a representation layer that are more or less disjunct. That way, widgets with similar underlying logic (like a toggle button and a check box, or a scroll bar and a progress indicator) can be implemented by a single widget class whose instances get assigned different representations.
The logic layer is part of the public API and consists of widgets and layouts that all derive from the base widget class. Widgets are single user interface elements like a label, button or text entry field, whereas layouts are containers that can be used to group multiple widgets and define their position on the screen. Toplevel windows or dialogs have to inherit from one of the layout implementations.
The representation layer is not exposed to the outside and the only hint at its existence is the widget::set_style method, which is used to specify a widgets desired look. Its parameter points to an XML file that describes the look and its elements in a specific format. Internally, a decoration_factory is used to create decorators that take care of rendering the actual widget. Most widgets use the std_decoration that can draw a background and a border.
The window_manager class keeps track of open windows, makes sure they are displayed on screen and receive keyboard or gamepad input. Focus is usually given to the topmost window. The manager also allows fading in and out of windows/dialogs as they are opened or closed.