Introduction

This tutorial explains how QuickGUI works on a high level, and includes what is needed by QuickGUI in order to be used in your application. For those who would like to see a full solution, a QuickGUIOgreDemo application is packaged with QuickGUI, which shows how Ogre and QuickGUI are used together.

History

Previously QuickGUI was built using Ogre as its primary method of rendering UI, however in this new version rendering has been abstracted out of the library. QuickGUI introduces a few abstract classes that must be implemented and passed in for QuickGUI to operate. Not only does this remove QuickGUI's dependency on Ogre, but it gives the developer control over how rendering occurs. This is especially useful if you work in an environment with certain limitations, ie power of 2 texture sizes, or use a specific or custom graphics library. In any case, you are in complete control of the rendering, so you can always adjust it without modifying QuickGUI source!

What if I don't know how to write a solution using Ogre for manual rendering?

In this tutorial I will provide an implementation that uses Ogre 1.7. It's important to realize that you can write your own rendering solution, and that the provided solution may not be the most efficient for all scenarios.

Creating QuickGUI Core

The Core class is similar to Ogre's Root class, providing access to all main subsystems within QuickGUI, and allowing creation and destruction of Interface objects. An Interface is a class that represents a collection of Window and RenderTarget objects, and will be covered later in this tutorial.

Core constructor:

/**
* Constructor. The passed in ResourceManager and SkinEffectCreator classes will NOT be owned by QuickGUICore, as
* they might be part of a class with scope larger than QuickGUI. Passing in a NULL value for the SkinEffectCreator
* is valid, as long as your UI Skins do not have any Skin Effects.
*/
Core(ResourceManager* m, SkinEffectManager* sem);

NOTE: Both the constructor and destructor are public, and should be created/destroyed by your application.

As seen in the comments, a ResourceManager and SkinEffectManager are required. The SkinEffectManager is part of the Skinning system, and will be covered in another tutorial. Passing in NULL for the SkinEffectManager is perfectly acceptable, provided you don't use any SkinEffect's. (which should be covered in the same tutorial as the SkinEffectManager)

ResourceManager

The ResourceManager class is an abstract class in QuickGUI, and meant to be derived and implemented by your application code. It performs the following functionality:

Access to Images by name. An Image is a class representing an image file on disk, and gives read-only access to pixel data. Depending on your implementation, this could also work for Images in memory.

Creation and destruction of RenderTexture objects. This class represents a texture in memory that supports drawing of Images and rectangles to it.

Creation and destruction of Texture objects. A Texture represents a image in memory, and provides both read and write access to pixel data.

NOTE: This class won't compile successfully until the Image, RenderTexture, and Texture classes have been defined and included!
NOTE: When you implement a ResourceManager for QuickGUI, you do not have to create a stand alone class specifically for QuickGUI. For example, your application could have a generic ResourceManager that inherits from the QuickGUI ResourceManager. Pass a pointer to this generic resource manager to the Core constructor, and QuickGUI will work just the same.

Image

A recognized QuickGUI Image must have the following interface:

public:/**
* Returns the ColorValue of the pixel at the position specified.
*/
virtual ColorValue getColorAtPosition(const Position& p)=0;/**
* Gets the name of this Image.
*/
virtual std::string getName()=0;/**
* Gets the size of this Image, in pixels.
*/
virtual Size getSize()=0;

Here is the provided implementation used by the QuickGUIOgreDemo application:
Image.h

RenderTexture

The RenderTexture interface is quite large. Here are a few of the APIs required by the class:

So now we've provided QuickGUI with methods to retrieve image data, and draw them to textures in memory. Whats next?

QuickGUI Scene

As you might have guessed, QuickGUI works by generating Textures and displaying them. We've provided methods to generate textures, but what about displaying them? The Scene class provides QuickGUI with this functionality via RenderTargets, the Overlay and UIPanel classes.

The Scene class should be thought of as the object representing your 3d scene. Overlays are 2d Panels that are drawn on top of your view, and do not change with Camera orientation. UIPanels are 3d Panels inside your scene, that can change orientation, and get smaller, larger, or move out of view, depending on your Camera's position and orientation within the 3d scene. Its worth noting that the UIPanel doesn't have to be implemented if you don't want to support 3d UI. Likewise, the Overlay class doesn't have to be implemented if you don't want to support 2d UI. Simply return NULL for the creation and accessor methods, allowing the Scene class to compile correctly.

Here is the provided implementation used by the QuickGUIOgreDemo application:
Scene.hScene.cpp

NOTE: This class won't compile successfully until the Overlay and UIPanel classes have been defined and included!

Overlay

The Overlay implementation is pretty easy to implement, since Ogre already has an Overlay implementation.

Some of the APIs required by the QuickGUI Overlay interface:

getPosition

getRenderTexture

getSize

getWindow

getZOrder

offsetPosition

setPosition

setRenderTexture

setSize

setWindow

setZOrder

NOTE: The Overlay interface inherits from the QuickGUI RenderTarget interface, so the derived class will need to implement APIs required by both interfaces.

UIPanel

In terms of Ogre, the UIPanel is a very simple ManualObject consisting of 6 vertices, or 2 triangles, that make up a quad. The required interface is very similar to the QuickGUI Overlay interface, except for getPosition and setPosition.

NOTE: The UIPanel interface inherits from the QuickGUI RenderTarget interface, so the derived class will need to implement APIs required by both interfaces.
NOTE: QuickGUI does not require any UIPanel APIs related to orientation, but that doesn't mean you shouldn't add these in. This will allow you to perform special effects such as UI facing certain targets, or changing orientation.

So now that we have a working Scene implementation, how do we let QuickGUI use it?

Interface

In QuickGUI, an Interface represents a grouping of UI Windows, the RenderTargets to display them, and allows for input injection to interact with the UI. Note that its perfectly acceptable to have multiple RenderTargets sharing the same Window (texture). This means you could have multiple Overlays and UIPanels displaying the same Window. Any change to the Window's texture will be reflected by all RenderTargets.

By default, the Interface class will automatically determine click, double click, and triple click events and inject them for you. If you want to inject these input events manually, call Interface::setDetermineClickEvents(false);.

What's next?

Now that you're all setup and ready ready to write GUIs, where do you start? The next tutorial will cover creating a basic UI. (however if you want to dive in, the Interface class is the place to start!)

Non Advanced Search or Natural Search

The documents are returned sorted on relevance depending on order, proximity, frequency of terms.

Advanced Search or Boolean Search

Default search behavior

By default, all search terms are optional. It behaves like an OR logic. Objects that contain the more terms are rated higher in the results and will appear first in their type. For example, wiki forum will find:

objects that include both terms

objects that include the term wiki

objects that include the term forum

Requiring terms

Add a plus sign ( + ) before a term to indicate that the term must appear in results. Example: +wiki forum will find objects containing at least wiki. Objects with both terms and many occurences of the terms will appear first.

Excluding terms

Add a minus sign ( - ) before a term to indicate that the term must not appear in the results. To reduce a term's value without completely excluding it, use a tilde. Example: -wiki forum will find objects that do not contain wiki but contain forum

Grouping terms

Use parenthesis ( ) to group terms into subexpressions. Example: +wiki +(forum blog) will find objects that contain wiki and forum or that contain wiki and blog in any order.

Finding phrases

Use double quotes ( " " ) around a phrase to find terms in the exact order, exactly as typed. Example: "Alex Bell" will not find Bell Alex or Alex G. Bell.

Using wildcards

Add an asterisk ( * ) after a term to find objects that include the root word. For example, run* will find:

objects that include the term run

objects that include the term runner

objects that include the term running

Reducing a term's value

Add a tilde ( ~ ) before a term to reduce its value indicate to the ranking of the results. Objects that contain the term will appear lower than other objects (unlike the minus sign which will completely exclude a term). Example: +wiki ~forum will rate an object with only wiki higher that an object with wiki and forum.

Changing relevance value

Add a less than ( < ) or greater than ( > ) sign before a term to change the term's contribution to the overall relevance value assigned to a object. Example: +wiki +(>forum < blog) will find objects that contain wiki and forum or wiki and blog in any order. wiki forum will be rated higher.