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
GG::Wnd-derived objects.
GG does not contain any actual code that will serialize a
GG::Wnd. Instead, each
GG::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
GG::Wnd subclass for example code. For full details on how the serialization works, see the serialization tutorial and the Boost.Serialization documentation.
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 GG::RadioButtonGroup::serialize() in
Button.h for an example.
GG::Font and GG::Texture objects that were part of the GUI's GG::FontManager and GG::TextureManager when saved will not be added back to these two structures when they are loaded.