Serialization

Motivation

One of the main design goals for GG is the editability of UI elements without recompilation. Another main goal is the capability of saving and restoring the state of the GUI. A secondary design goal is the capability of serializing UI elements for network transmission and receipt. To satisfy all these requirements, GG uses the boost.serialization library to serialize Wnd-derived objects.

Details

GG does not contain any actual code that will serialize a Wnd. Instead, each Wnd subclass contains a serialize() template method which may be invoked by user code to perform serialization. The user must then create a boost serialization archive, and save/load the desired windows to/from the archive. To be serializable, user-created subclasses need to define a serialize method that first serializes its base class, then serializes any subclass-specific data; see any Wnd subclass for example code. For full details on how the serialization works, see the serialization tutorial and the boost.serialization documentation.

Caveats

Signals are not currently serializable. This means that when a class is created from an input serialization archive, all its signals must be reconnected to their slots (and any signals connected to it should be reconnected as well). Many of the built-in GG controls must reconnect signals when loaded; such classes have a private ConnectSignals() method that is called at load time. See RadioButtonGroup::serialize() in GGButton.h for an example.

Font and Texture objects that were part of the GUI's FontManager and TextureManager when saved will not be added back to these two structures when they are loaded.

---