The following is intended as a high level overview of the CEGUI system; the core components are described as are the general relationships between the components. Once you have finished reading this section you should have a comfortable understanding of the way CEGUI operates.

Introduction

Much of the functionality of CEGUI is exposed - in one way or another - via abstracted interfaces that allow the user of the library to customise the precise way that various functionality is implemented. Whether it's rendering imagery, loading image data, parsing XML files, or any number of other aspects, there usually exists a mechanism for the library user to select - or create - a solution tailored to the needs of their individual project.

Low Level Interface Objects

For the most part, the entire CEGUI system is bootstrapped in one step when the CEGUI::System object is created. The user passes the System::create function their choice of Renderer object as well as other options like a ResourceProvider, an XMLParser and an ImageCodec (if any of three latter objects are not provided default options are used instead). These four objects - that is the Renderer, XMLParser, ImageCodec and ResourceProvider - essentially form a bridge from the CEGUI world to the world outside; these objects are key, so each will be briefly described here so you know the role they play.

CEGUI::Renderer: The Renderer object is the top level implementation of a set of interfaces that perform rendering - and other video system related services - for CEGUI.

CEGUI::ResourceProvider: The ResourceProvider object basically loads data indicated by a resource group and a resource name into memory buffers. The exact mechanism employed to do this is not specified - so while for the most part this will likely involve loading file based data from disk, it's possible for a ResourceProvider implementation to use any other mechanism instead (or as well).

CEGUI::XMLParser: The XMLParser abstracts access to lower level XML parsing libraries, such as Expat or Xerces-C++. The XMLParser is then used by various components within the CEGUI system when they require XML data - obtained via the ResourceProvider - to be parsed.

CEGUI::ImageCodec: The ImageCodec abstracts access to lower level image reading libraries, such as FreeImage or DevIL. The ImageCodec is then used by other CEGUI system components to parse image file data - obtained via the ResouceProvider - into source imagery used by CEGUI::Texture objects - as created by the Renderer object.

System and Manager Objects

The System object provides system wide options, settings and functions, as well as access to other non-singleton objects (such as the previously described Renderer, ResourceProvider, XMLParser and ImageCodec objects). CEGUI::System also contains the input injection interface that you use to pump externally generated inputs - such as mouse and keyboard input - into the CEGUI system.

When the core CEGUI::System object is created the system also creates a set of manager objects that are subsequently used to interact with various parts of CEGUI. The main group of managers - as used in the majority of applications - are the ImagesetManager, the FontManager, the SchemeManager and the WindowManager. The remaining manager objects, the WindowRendererManager, the WindowFactoryManager and the WidgetLookManager are generally only needed by library users when they come to extend or customise the windows and widgets available to the system.

The key to understanding CEGUI is in these managers. Generally you do not directly create and destroy objects in CEGUI (meaning you do not use the C++ new and delete keywords), but rather you use an appropriate manager object to create the object for you. The managers keep track of all the objects created and - because each created object has a name - you can use the managers to get access to created objects at a later time. This arrangement also aids in cleaning up the system when you're done; CEGUI will destroy any remaining objects automatically when it is closed down (via the System::destroy function).

CEGUI::ImagesetManager: The ImagesetManager manages CEGUI::Imageset objects. An Imageset represents a series of named regions defined upon some source surface (texture). Each named region defined represents a CEGUI::Image and is typically the lowest level abstraction of imagery used by CEGUI; when you - or the system itself - wants to draw something, this typically entails an Image object submitting geometry to a GeometryBuffer provided via the Renderer.

CEGUI::FontManager: The FontManager manages CEGUI::Font objects. In CEGUI a Font is - unsurprisingly - an abstraction of a typeface of some kind and is used to render textual information. You should be aware that - beneath the surface - the entire font system is actually built on top of the Imageset system; when a font is used to draw text it accesses one or more Imageset objects holding the imagery for the text glyphs to be drawn.

CEGUI::SchemeManager: The SchemeManager manages CEGUI::Scheme objects. A CEGUI Scheme is essentially a collection of references to other resources and so provides a means to group resources and definitions that are to be loaded together; essentially a Scheme represents a top-level means to form a GUI 'skin'.

CEGUI::WindowManager: The WindowManager manages CEGUI::Window based objects and is the means by which you will create and manage the windows and widgets of your GUIs.

CEGUI::WindowFactoryManager: Every type of Window based object is required to have a WindowFactory based object that creates and destroys instances of that specific window type. WindowFactoryManager is where these WindowFactory objects are registered with the system. Unless you are registering new concrete Window based classes with the system (or are doing some other advanced operation), you will not need to directly interact with the WindowFactoryManager.

CEGUI::WindowRendererManager: The core Window based objects generally do not perform any specific drawing operations; rather they are only concerned with the logic of the window's implementation. The visual aspects of window objects are delegated to an associated WindowRenderer object. The WindowRendererManager keeps track of the WindowRenderer objects registered with the system. Again, except when creating new window or widget types, you will not usually need to interact with the WindowRendererManager.

CEGUI::WidgetLookManager: The WidgetLookManager is the last manager object, it is part of the Falagard skinning system for CEGUI and manages WidgetLookFeel objects as loaded from XML LookNFeel files (actually it's possible to define such objects in code alone, but this is rarely - if ever - done). Again, unless you're accessing WidgetLookFeel objects from a custom Window or WindowRenderer implementation, you will not usually need to use the WidgetLookManager directly.

Falagard Mappings

The Window, WindowRenderer and WidgetLookFeel objects are the CEGUI system's 'holy trinity'. They each provide part of the functionality required to represent a fully working, interactive window or widget, and are combined via what is known as a "Falagard Mapping" (typically defined in scheme XML files). A falagard mapping is a means to provide a type name to a grouped concrete window or widget type providing the core logic of the widget, a window renderer providing high-level rendering instructions, and a WidgetLookFeel providing the lower-level definitions to be used by the window and window renderer. It is these mapped type names that are typically used when creating windows within the system and frees you from the complexity of needing to create and link these objects manually.