CEGUI Wiki - Crazy Eddie's GUI System (Open Source) - User contributions [en]

Create ImageButtons

2007-10-22T10:49:15Z

Pompei2: /* Draw it ! */

If you write a GUI for a game, at some time comes the point where you want to create the most exciting kind of buttons: ImageButtons ! But care, I'm not talking about a default button frame, that has a picture instead of a text, I'm talking about ''completely'' self-drawn buttons. I've found two ways to accomplish that task, both are nice.

== Preparations ==
There are a few tasks we have to accomplish before being able to create an ImageButton.

=== Draw it ! ===
The most important thing is, of course, draw the pictures. If you don't want to accomplish this, ask your graphics artist :)
You have to draw 4 pictures/button, wich represents the four states:
#Normal: That is how the button looks like most of the time.
#Hover: This is how the button should look when the mouse comes over it.
#Pushed: When the user clicks the mouse button (and holds it down a bit) over the button, it looks like this.
#Disabled: You can imagine what this is.

This is the file we'll use for this HOWTO and as you see, i didn't ask my graphics artist to do one :p
You can find all other files (source code, data files) there too.
[[http://pompei2.cesar4.be/cegui/imgButton/]]
Edit: shit the link is currently dead ... I hope I find the files so I can upload them again, but atm everything that is written here must be enough. On questions/problems just ask in the forum.

=== The Imageset ===
When I talk about an Imageset, I mean two files: The picture file (.tga, .png, or whatever) and the description (.imageset) file. The picture file can contain a lot of images, but it's size has to be a power of two. The description file is an xml file wich gives a name to a (rectangular) location in the picture. So you can call the location (150,150,32,32) "UnitIcon" for example.

'''An example for a .imageset file:'''
<?xml version="1.0" encoding="UTF-8"?>

<Imageset Name="THEButton" Imagefile="THEButton.png" >
<Image Name="btnNormal" XPos="0" YPos="0" Width="64" Height="20" />
<Image Name="btnHover" XPos="0" YPos="20" Width="64" Height="20" />
<Image Name="btnPushed" XPos="0" YPos="40" Width="64" Height="20" />
<Image Name="btnDisabl" XPos="0" YPos="60" Width="64" Height="20" />
</Imageset>
We will use this imageset in our examples. It defines four named images: btnNormal, btnHover, btnPushed and btnDisabl (saved in the file "THEButton.png"). The whole imageset is called "THEButton" and saved in a file named "THEButton.imageset".

How to use this imageset now ? This is very simple, you just have to do this in your initialisation code:
// Load the THEButton Imageset that has the pictures for our button.
CEGUI::ImagesetManager::getSingleton().createImageset( "THEButton.imageset" );
That's all ! Of course, you should do this in a try/catch block.

If, for some wicked reason, you want to do something in code with this imageset, you can either save the pointer that the function above returns, or you just get that pointer if you know the name of the imageset (what you usually do), using this function:
CEGUI::Imageset *m_pImageSet = CEGUI::ImagesetManager::getSingleton().getImageset( "THEButton" );

Enough about imagesets.

== The programmer's job ==
Now we can create the button itself (in two different ways):

=== The first way: mainly in code ===
One way is to create the button in code, you usually do this if you only know wich button to display at runtime. Maybe a strategy game is the best to illustrate this. Imagine you have the buttonspanel, a place on screen with an array of buttons. The buttons that are present there depend on something (like wich unit is currently selected or so). The first thing you have to do, is not in code. Create one layout file for every button. The file should look somewhat like this:

'''Content of button1.layout version 0.1'''
<?xml version="1.0" encoding="UTF-8" ?>
<GUILayout>
<Window Type="TaharezLook/ImageButton" Name="btnNewGame">
<Property Name="UnifiedPosition" Value="{{0,0},{0,0}}" />
<Property Name="UnifiedSize" Value="{{0,64},{0,20}}" />
<nowiki>
</nowiki>
<Property Name="NormalImage" Value="set:THEButton image:btnNormal" />
<Property Name="HoverImage" Value="set:THEButton image:btnHover" />
<Property Name="PushedImage" Value="set:THEButton image:btnPushed" />
<Property Name="DisabledImage" Value="set:THEButton image:btnDisabl" />
<nowiki></nowiki>
</Window>
</GUILayout>

If you have an imagebutton but you want it to have a caption, you could write this kind of layout file:

'''Content of button1.layout version 0.2'''
<?xml version="1.0" encoding="UTF-8" ?>
<GUILayout>
<Window Type="TaharezLook/ImageButton" Name="btnNewGame">
<Property Name="UnifiedPosition" Value="{{0,0},{0,0}}" />
<Property Name="UnifiedSize" Value="{{0,64},{0,20}}" />
<nowiki>
</nowiki>
<Property Name="NormalImage" Value="set:THEButton image:btnNormal" />
<Property Name="HoverImage" Value="set:THEButton image:btnHover" />
<Property Name="PushedImage" Value="set:THEButton image:btnPushed" />
<Property Name="DisabledImage" Value="set:THEButton image:btnDisabl" />
<nowiki></nowiki>
<Window Type="TaharezLook/StaticText" Name="btnNewGame_text__">
<nowiki>
</nowiki>
<Property Name="UnifiedPosition" Value="{{0,0},{0,0}}" />
<Property Name="UnifiedSize" Value="{{1,0},{1,0}}" />
<nowiki></nowiki>
<Property Name="FrameEnabled" Value="False" />
<Property Name="BackgroundEnabled" Value="False" />
<nowiki></nowiki>
<Property Name="HorzFormatting" Value="WordWrapCentred" />
<Property Name="VertFormatting" Value="Middle" />
<nowiki>

</nowiki>
<Property Name="Disabled" Value="True" />
<nowiki></nowiki>
<Property Name="Text">New game</Property>
</Window>
</Window>
</GUILayout>

This adds a child window of type StaticText, with no border and background, that takes all the place in the button, so we can center it. If your caption has to be not centered, play with the values.

A problem that comes up now, is that if the user clicks on the button, the click will be absorbed by the StaticText, and won't reach the button. That's bad. I searched around and found the following two propertys:
<Property Name="MousePassThroughEnabled" Value="True" />
<Property Name="DistributeCapturedInputs" Value="True" />
But both didn't seem to work as expected, I asked the forums and lindquist told me that "If all you want is a simple label added to the ImageButton then adding a TextComponent in the looknfeel is a much cleaner solution.". He is probably right, but I didn't struggle with looknfeels yet. If you achieved this, you can tell me or add a chapter to this wiki :)

The solution he suggested (and the only one wich worked, if i remember correctly, is disabling the staticText (like in the complete code written above)

<Property Name="Disabled" Value="True" />

Now all you need to do to load and show the button are the following four lines of code.

CEGUI::Window *w = CEGUI::WindowManager::getSingleton().loadWindowLayout( "button1.layout" );
rootWin->addChildWindow( w );
w->setPosition( CEGUI::UVector2( CEGUI::UDim(0.5f,-32.0f), CEGUI::UDim(0.5f,-10.0f) ) );
w->setVisible( true );
Supposing rootWin is your current root window, or any other window you want to put the button in.
We set the position to be the center (0.5f) minus the half the height/width of the button, so the button is really centered.
Of course, you can do everything else you want before (and while) showing the button.

That's it ! now you can work with the button however you want :)

=== The second way: Let the power of layout guide you ===
I suppose you read the first way, because they are very similar and I won't rewrite the whole code here. The main difference is that if you like layouts, you'll already have declared all your windows in layout files. The the "'''Content of button1.layout version 0.2'''" won't be alone in a layout file of it's own, but it will be in your already existing layout files.
You still have to load the Imageset. I Provided a sample, named imgButtonSample.layout

That's it ! If you got suggestions, corrections or whatever feedback, just tell me.
----

--[[User:Pompei2|Pompei2]] 11:18, 11 January 2007 (PST)

FAQ

2007-08-02T12:24:30Z

Pompei2:

== General Questions ==
=== What is CEGUI? ===
CEGUI stands for ''Crazy Eddie's Gui System''; a free library providing windowing and widgets for graphics APIs / engines where such functionality is not natively available, or severely lacking. The library is object orientated, written in C++, and targeted at games developers who should be spending their time creating great games, not building GUI sub-systems!

CEGUI is used as the GUI of choice in the [http://www.ogre3d.org Ogre3D project] but supports Microsoft® DirectX® 8.1 and 9, OpenGL, and the Irrlicht engine natively.

CEGUI was started by Paul Turner ("[[User:CrazyEddie|CrazyEddie]]") about two years ago and is currently in it's second major revision, "Mk2". The project supports windows, linux and MacOS.

=== How is CEGUI licensed? ===
Up and until version 0.4.1, CEGUI '''is''' licensed under [http://www.gnu.org/licenses/lgpl.html LGPL], which basically means you can dynamically link to it (ie. use it as a library) in a non-GPL project, as long as you fulfill the other requirements of the LGPL.

However, from 0.5 on the library is released under the [http://www.opensource.org/licenses/mit-license.php MIT] license, which is less restrictive then LGPL. You may for example statically link to libraries. The main reason for this switch is the fact that the Ogre3D project has started to provide dual licensing to allow console development. And in order to keep CEGUI as their preferred GUI system, we have switched as well.

=== What is the situation with the Falagard components and the Creative Commons license? ===
There is no situation! The Creative Commons license only applies to the documentation where that notice appears; the source code, libraries, and all other materials relating to the Falagard skinning system are licensed under LGPL or MIT (depending upon the version; see above).

=== Why is the Falagard documentation licensed separately? Why is it not LGPL/MIT like the rest of the library? ===
Originally that documentation was only to be available as a PDF file intended for self-printing into a mini-book, and the "this work" portion of the license notification applies to the text of that book; the documentation is considered a separate work from the code / library itself, and so it licensed separately.

=== How much does CEGUI cost? ===
Nothing. The use of CEGUI is totally free within the bounds of the license as described above.

=== I am developing a commercial, closed-source product. Should i use the 0.4 or 0.5 version of the library? ===
When you are creating a product for PC, where it is possible for users to update any of your used third-party DLL's (a requirement for LGPL), you can choose both versions. However if you are shipping a product on a read-only device, such as a console DVD, you must use 0.5 or higher, because the MIT license does not require that users can update anything.

However before deciding, do always carefully check the mentioned licenses to make sure that your project doesn't do something uncommon.

=== I am not happy with the LGPL / MIT license, do you offer alternative licensing? ===
No. Alternative licensing is not available, nor is it planned. But you won't find anything much less restrictive then the MIT license.

=== Does CEGUI rely upon any third party libraries? If so what are they? ===
CEGUI currently depends upon the following external libraries:
{| width="100%"
|| '''Library''' || '''Required''' || '''Url''' || '''License'''
|-
|| FreeType2 || yes || [http://www.freetype.org/freetype2/index.html http://www.freetype.org/freetype2/index.html] || BSD-like [http://www.freetype.org/FTL.TXT FreeType License] ou [http://www.freetype.org/GPL.TXT GPL]
|-
|| Perl C Regular Expression || yes || [http://www.pcre.org/ http://www.pcre.org/] || [http://www.pcre.org/license.txt BSD]
|-
|| Xerces-C++ || no || [http://xerces.apache.org/ http://xerces.apache.org/] || [http://www.apache.org/licenses/LICENSE-2.0.html Apache Software License, Version 2.0]
|-
|| Expat || no || [http://expat.sourceforge.net/ http://expat.sourceforge.net/] || [http://www.opensource.org/licenses/mit-license.html MIT]
|-
|| Libxml || no || [http://www.xmlsoft.org/ http://www.xmlsoft.org/] || [http://www.opensource.org/licenses/mit-license.html MIT]
|-
|| DevIL || no || [http://openil.sourceforge.net/ http://openil.sourceforge.net/] || [http://openil.sourceforge.net/license.php LGPL License Version 2.1]
|}
You will also require a supported rendering system, and some form of input library.

=== Do I have to compile the third part libraries myself? ===
It depends. Under Linux and similar systems, you will need to perform your own compilation. For Microsoft® Windows® users, we have supplied packages containing binary versions of the libraries for a selection of popular compiler configurations. See the "Current Releases" on the home page.

=== You mentioned something about "supported rendering systems", what's that all about and which systems are supported? ===
CEGUI can be used with various rendering systems. There are currently CEGUI renderer modules for Microsoft® DirectX® 8.1 and 9, OpenGL, the Ogre engine, and the Irrlicht engine.

=== There is no renderer module for my rendering engine or API of choice, will other rendering system be supported? ===
It is likely that, over time, CEGUI will add support for other APIs and engines. Having said this, it is fairly simple to write your own renderer module for CEGUI, so you might consider taking that option if you do not want to wait.

=== And what about input libraries? ===
CEGUI requires you to ''inject'' inputs into it, these inputs can come from any source that you choose. All you need to do is pass mouse movements, mouse button up and down events, and keyboard inputs to CEGUI.

=== Why doesn't CEGUI collect its own inputs? Why do I need to inject the inputs myself? ===
CEGUI does not collect its own input so that the system can remain as flexible as possible. We don't want to tie people down to one system or input library.

=== I have seen mention of a Lua scripting module, how can I get this? ===
The Lua scripting module is provided with CEGUI and resides in the same source repository. Downloading CEGUI binary/source/svn will get you everything you need.

=== What is the Mk-1 version of CEGUI? ===
The Mk-1 version was a Windows®/DirectX® only library and was really a dry run for what became the Mk-2 system. There was only ever 'alpha' versions of the Mk-1 code, and it is now considered obselete and is not supported.

=== I am having major troubles integrating CEGUI with my project, will you do it for me? ===
No. The CEGUI developers have enough to do without writing users projects for them. Refer to the Howto's and Tutorials from the home page.

=== I have (or think I have) found a bug. How should I proceed? ===
If you are certain that it's a bug and not, for example, a misunderstanding of what is happening, then the bug should be reported via the [http://www.cegui.org.uk/mantis/index.php | Mantis Tracker] However, before submitting a bug to the tracker, it is asked that you first do a quick search to see if the bug has already been reported. If you are unsure whether something is a bug or not, then it may be discussed on the web site forums prior to submitting a bug report to the project bug tracker.

=== I notice that feature/widget 'X' is missing. Will this be added to CEGUI? ===
Requests for new features and/or widgets are welcomed in this forum: http://www.cegui.org.uk/phpBB2/viewforum.php?f=3&sid=587eedf3463c00490686f8cddc61a257
This is the best way because most people will read it, including the team. This helps others to give input as well, which migth result in clearly defined requests.

Note that no promises are made with regards to which features will and will not be added, or how long such things will take, but all requests will be seriously considered.

=== How can I get involved with CEGUI development? ===
Each new member gets added by invitation by the current team. Most probably because that person has contributed some valuable patches, or is of great help in the forums. It will of course depend on the current state of the project to know which positions are required.

So the best way to become involved is to show your face at the web site forums, the irc channel, and state what your intentions are (to help in avoiding duplicated effort), thereby becoming a constructive individual for CEGUI and its community.

=== Is there managed code / Microsoft .Net support for the CEGUI library? ===
Yes, there is ''ceguisharp'' at http://ceguisharp.sourceforge.net/ This is a C# port of the library which will support Managed Direct 3D, OpenGL, as well as higher-level engines such as the excellent Axiom rendering engine.

=== This FAQ doesn't answer my question, what should I do now? ===
Feel free to post your question on the web site forums, somebody will gladly answer your question and/or offer further advice.

== Building CEGUI ==

This section has moved to [http://www.cegui.org.uk/wiki/index.php/HOWTO:_Obtain_the_library_source_from_subversion New location]

== Usage Questions ==
''(This whole section should be moved to a Tutorial or a Howto).''
=== What is the correct way to subscribe for an event? ===
Event notification is a vital aspect of GUI programming. CEGUI handles those using subscribers.
In order to subscribe a window for an event, you have to call the method 'Window::subscribeEvent', passing the function
to be called when the specified event occurs, and the instance on which the method is called.

class MyButtonHandler
{
private:
PushButton* mButton;

public:
MyButtonHandler::MyButtonHandler(PushButton* btn) : mButton(btn)
{
btn->subscribeEvent(PushButton::EventClicked, Event::Subscriber(&MyButtonHandler::ButtonClicked,this));
}

bool MyButtonHandler::ButtonClicked(const EventArgs&)
{
//This function gets called when the button is clicked
std::cout << "Button clicked" << std::endl;
}

The 'subscribeEvent' method returns an Event::Connection, which can be used later to unsubscribe for a registered event with
the 'disconnect' method.

Event::Connection myCon = btn->subscribeEvent(...);

...

myCon->disconnect();

In order to totally remove the event itself, you have to call the 'removeEvent' function:
all the connections to the specified event will be disconnected.
There's also an Event::ScopedConnection, which can be used to auto-unsubscribe when the event goes out of scope.

Similar way for the scripted events, which can be subscribed with the 'subscribeScriptedEvent' method.
In addition, you can do it in XML, using this syntax:

<Event Name="Clicked" Function="luabtn_clicked" />

=== How can I make the ListBox highlight the selected item? ===
In order to highlight selected items you need to set selection brush image and the selection colours of that item. The selection image is modulated by the colours you set. Note, that the alpha component needs to be smaller than 1.0, for the content of the selected item to be seen.
// set selection highlight to a half transparent blue to red gradient.
colour blue(0.0, 0.0, 1.0, 0.5);
colour red(1.0, 0.0, 0.0, 0.5);
myListBoxItem->setSelectionColours(blue, blue, red, red);
// this default image is a simple white rectangle
myListBoxItem->setSelectionBrushImage("TaharezLook", "ListboxSelectionBrush");

=== How can I remove the border of a StaticImage? ===
Either put the following property into the window definition:
<Property Name="FrameEnabled" Value="false" />
Or set it by code:
myStaticImage->setFrameEnabled(false);

=== How can I set the background of a StaticImage? ===
The first thing you need in order to do this is an Imageset that defines the Image that you wish to use. When wanting to use an image file for this as you suggest, you basically have an imageset defined like this:
<?xml version="1.0" ?>
<Imageset Name="BackdropImageset" Imagefile="backdrop.tga" NativeHorzRes="1024" NativeVertRes="768" AutoScaled="true">
<Image Name="Backdrop" XPos="0" YPos="0" Width="1024" Height="768" />
</Imageset>

What this does is define an Imageset using the backdrop.tga. A single image "Backdrop" is defined that starts at location (0,0) and is 1024 x 768 in size. You should be careful in that the source image file should have dimensions that are powers of two - this is because the image is loaded as a texture, and may be stretched if the powers-of-two requirement is not observed.<br>
Once you have your imageset defined, you can load it either by adding a reference to it in whichever scheme you are loading, or manually using the ImagesetManager:
CEGUI::ImagesetManager::getSingleton().createImageset("myImageset.imagset");
Once the thing is loaded, you set the image into the StaticImage like so:
myStaticImage->setImage("BackdropImageset", "Backdrop");
Notice that the names we specify here are the ones that were originally specified in the imageset XML file.<br>

=== I can't see the items I've added to my Combobox, how do I get the list to show when I press the button? ===
The height you specify for the combobox widget includes the height of the drop down list; it's not just for the 'Editbox' portion of the widget (the height of which is usually automatically determined based upon the font). Ensure that when specifying the height for your combobox, you have provided sufficient space for the list to appear.

=== What properties are available for use in XML layouts, and what format do I use for the value strings? ===
If you start at the documentation for the base Property class ([http://www.cegui.org.uk/api_reference/classCEGUI_1_1Property.html Property base]), you will get an inheritance diagram showing all properties in the system. When you click one, you'll get its page. Each page has a description of the format in which you should provide its value.

Besides, as an overview, each widget has its properties placed within an appropriately named C++ namespace within the [http://www.cegui.org.uk/api_reference/namespaces.html namespaces section of the API reference].

Also, remember that properties are inherited. So for example, when looking up properties for a PushButton, also check the properties for ButtonBase and Window too - since these properties are also available to you.

An [http://www.cegui.org.uk/wiki/index.php/SetProperty overview of all properties of every widget], with a short description of each property has been automatically generated by [http://www.cegui.org.uk/wiki/index.php?title=PropertyFinder Rackle's PropertFinder]

=== (How) can I create a menu ? ===
Yes you can. Rackle wrote [http://www.cegui.org.uk/wiki/index.php?title=MenuAndPopup an article] about how to create menus, submenus and popup menus, including some code.

Cool window effects

2007-07-02T09:24:26Z

Pompei2: /* Inactive windows become transparent */

= Inactive windows become transparent =
'''WARNING ! As for now (02.07.2007), this code does make all your tooltips transparent, I'm working on a solution.'''

'''Problem solved (02.07.2007). If you used the old code, please replace by the new.'''

Please discuss this snippet within the [[http://www.cegui.org.uk/phpBB2/viewtopic.php?p=11786 cool window effects - Inactive windows become trans.]] thread.

Do you know about the [http://vizzzion.org/images/blog/composite.png cool effects that the composite extension can create] on linux ? There are many. I wanted to implement one into my game: make the [http://img337.imageshack.us/img337/9398/windowtransparencyue1.png inactive windows become transparent] and only the active one be 100% opaque. (see the links in this sentence for screenshots.) This effect can be interesting if you want your users to concentrate 100% on the active window and the inactive ones aren't important at this moment. But what if the user has to see two windows or more at the same time (and with full opacity) ? We'll see how to handle this.

== The theory ==
There is more then one way to achieve this, but I'll only present the one I chose. CEGUI has something that is called global events. These are events that are fired independently on the widget they apply to. I'll try with an example: sometimes you need to know when a button is clicked, no matter what button it is, you want to know it for EVERY button. This is what global events are for.

We'll subscribe to two global events: "a window gets activated" and "a window gets closed". When a window gets activated, we add it to a stack which we use to keep track of the windows and the order they where activated. We also make the last active window become transparent. When a window gets closed, we remove it from the stack and activate the one that is on the top of the stack now. (that is the window that was active just before the one we just closed.)

We keep the root window away from it, that means we never make the root window transparent, because this would make the tooltips become transparent. You need to have an empty root window that is a container for your other windows.

== The praxis (code) ==
Now let's go ! First, we need to register callback functions to the two global events:
<code><cpp/>
CEGUI::GlobalEventSet::getSingleton( ).subscribeEvent( CEGUI::Window::EventNamespace + "/" + CEGUI::Window::EventActivated,
CEGUI::Event::Subscriber(&onWindowActivated) );
CEGUI::GlobalEventSet::getSingleton( ).subscribeEvent( CEGUI::Window::EventNamespace + "/" + CEGUI::Window::EventDestructionStarted,
CEGUI::Event::Subscriber(&onWindowClosed) );</code>

We also need a stack to keep track of the windows. I chose to use the std::list type instead of the std::stack, because we need to be able to either delete all references of one element or to search the stack. So here it is:
<code><cpp/>std::list<CEGUI::Window *> pWinHistory;</code>

Also, don't forget to put your root window just before setting it as the root window:
<code><cpp/>pWinHistory.push_back(pMyRootWindow);
CEGUI::System::getSingleton().setGUISheet(pMyRootWindow);
</code>

One thing you need to know about the root window is that you need an empty root window, containing one or more child windows that contain all GUI items. Your root window will never become transparent, thus you need an empty "container" root window.

And now we implement our two callback functions. I excessively commented the functions.

onWindowActivated:
<code><cpp/>/// Called everytime a window gets activated.
/** This function is called by CEGUI every time that a window gets the focus.
*
* Currently, we use this function to keep track of the order that windows where
* active, so when closing a window we can activate the last one, as this isn't
* done automatically by CEGUI.
*
* \param e The event arguments.
*
* \return Always true.
*
* \author Pompei2
*/
bool onWindowActivated( const CEGUI::EventArgs &ea )
{
try {
const CEGUI::WindowEventArgs& we = static_cast<const CEGUI::WindowEventArgs&>(ea);
CEGUI::Window *pLastWin = pWinHistory.back( );

// We only work with FrameWindows.
if( !we.window->testClassName( CEGUI::FrameWindow::EventNamespace ) )
return true;

// If it is the same window as before, ignore it.
if( pLastWin == we.window )
return true;

if( pLastWin != CEGUI::System::getSingleton().getGUISheet() ) {
// If every time a window gets activated we make the last active window become
// transparent, this will result in all inactive windows being transparent.
pLastWin->setProperty( "Alpha", "0.25" );

// But we never make the root window transparent, as this would make all tooltips
// become transparent, and we don't want this !
}

// We need the active window to not inherit the transparence of its parents.
we.window->setProperty( "InheritsAlpha", "false" );

// Finally, we add the new window to the stack.

// One could also check if it's already present in the stack and if yes, just put it on the top.
// You would have to do this if you want to set the transparency depending on the window's position
// in the stack (see "Extending the effect").
pWinHistory.push_back( we.window );
} catch( CEGUI::Exception& e ) {
fprintf( stderr, "CEGUI error: %s\n", e.getMessage( ).c_str( ) );
return true;
}

return true;
}</code>

And onWindowClosed:
<code><cpp/>/// Called everytime a window gets closed.
/** This function is called by CEGUI just before a window gets closed.
*
* Currently, we use this function to activate the previous window
* when closing this one, as it's not done automatically by CEGUI.
*
* \param e The event arguments.
*
* \return Always true.
*
* \author Pompei2
*/
bool onWindowClosed( const CEGUI::EventArgs &ea )
{
try {
const CEGUI::WindowEventArgs& we = static_cast<const CEGUI::WindowEventArgs&>(ea);
CEGUI::Window *pLastWin = NULL;

// We only work with FrameWindows.
if( !we.window->testClassName( CEGUI::FrameWindow::EventNamespace ) )
return true;

// Delete the current window from the stack.
// CARE: std::list::remove removes ALL occurences of we.window from the stack !
// This is VERY important to know, as if you activate window A, then window B and then A again,
// the stack will contain A twice: {A,B,A}.
pWinHistory.remove( we.window );

// Now we get the window that was active before the current one:
pLastWin = m_pWinHistory.back( );

// re-activate it (like windos, linux, .. all do).
pLastWin->activate( );

// And set it to be opaque again.
// You could either do this here or you do this in the onWindowActivate function, the result is the same,
// as the call to CEGUI::Window::activate above results in onWindowActivate to be called.
pLastWin->setProperty( "Alpha", "1.0" );
} catch( CEGUI::Exception& e ) {
fprintf( stderr, "CEGUI error: %s\n", e.getMessage( ).c_str( ) );
return true;
}

return true;
}</code>

That's all.

One important thing you might not know yet, is that CEGUI DOESN'T activate a window that gets shown. you have to manually activate a window when you create it (and want it to be active, of course).

== Extending the effect ==
* You could also automatically activate a window as soon as it's shown. for this you could subscribe to the "a window gets shown" global event and then just call ea.window->activate( );
Edit: Hmm I tried this one but wasn't able to get it to work. If someone has success, please tell us how you did it in the forums.

* You could try to make the window's transparency degree dependent on it's position in the stack. That means the most recent windows get less transparent while the "oldest" windows get very transparent. To do this, just loop trough the stack - that would be a list - and set every window's transparency accordingly. Do this when a window gets active AND when a window gets closed. You would also need to never have the same window twice in the stack, as it would screw your results up.

--[[User:Pompei2|Pompei2]] 06:00, 6 May 2007 (PDT)

----
----
you can add more cool effects here.

Cool window effects

2007-07-02T09:21:28Z

Pompei2: /* The theory */

= Inactive windows become transparent =
'''WARNING ! As for now (02.07.2007), this code does make all your tooltips transparent, I'm working on a solution.'''

Please discuss this snippet within the [[http://www.cegui.org.uk/phpBB2/viewtopic.php?p=11786 cool window effects - Inactive windows become trans.]] thread.

Do you know about the [http://vizzzion.org/images/blog/composite.png cool effects that the composite extension can create] on linux ? There are many. I wanted to implement one into my game: make the [http://img337.imageshack.us/img337/9398/windowtransparencyue1.png inactive windows become transparent] and only the active one be 100% opaque. (see the links in this sentence for screenshots.) This effect can be interesting if you want your users to concentrate 100% on the active window and the inactive ones aren't important at this moment. But what if the user has to see two windows or more at the same time (and with full opacity) ? We'll see how to handle this.

== The theory ==
There is more then one way to achieve this, but I'll only present the one I chose. CEGUI has something that is called global events. These are events that are fired independently on the widget they apply to. I'll try with an example: sometimes you need to know when a button is clicked, no matter what button it is, you want to know it for EVERY button. This is what global events are for.

We'll subscribe to two global events: "a window gets activated" and "a window gets closed". When a window gets activated, we add it to a stack which we use to keep track of the windows and the order they where activated. We also make the last active window become transparent. When a window gets closed, we remove it from the stack and activate the one that is on the top of the stack now. (that is the window that was active just before the one we just closed.)

We keep the root window away from it, that means we never make the root window transparent, because this would make the tooltips become transparent. You need to have an empty root window that is a container for your other windows.

== The praxis (code) ==
Now let's go ! First, we need to register callback functions to the two global events:
<code><cpp/>
CEGUI::GlobalEventSet::getSingleton( ).subscribeEvent( CEGUI::Window::EventNamespace + "/" + CEGUI::Window::EventActivated,
CEGUI::Event::Subscriber(&onWindowActivated) );
CEGUI::GlobalEventSet::getSingleton( ).subscribeEvent( CEGUI::Window::EventNamespace + "/" + CEGUI::Window::EventDestructionStarted,
CEGUI::Event::Subscriber(&onWindowClosed) );</code>

We also need a stack to keep track of the windows. I chose to use the std::list type instead of the std::stack, because we need to be able to either delete all references of one element or to search the stack. So here it is:
<code><cpp/>std::list<CEGUI::Window *> pWinHistory;</code>

Also, don't forget to put your root window just before setting it as the root window:
<code><cpp/>pWinHistory.push_back(pMyRootWindow);
CEGUI::System::getSingleton().setGUISheet(pMyRootWindow);
</code>

One thing you need to know about the root window is that you need an empty root window, containing one or more child windows that contain all GUI items. Your root window will never become transparent, thus you need an empty "container" root window.

And now we implement our two callback functions. I excessively commented the functions.

onWindowActivated:
<code><cpp/>/// Called everytime a window gets activated.
/** This function is called by CEGUI every time that a window gets the focus.
*
* Currently, we use this function to keep track of the order that windows where
* active, so when closing a window we can activate the last one, as this isn't
* done automatically by CEGUI.
*
* \param e The event arguments.
*
* \return Always true.
*
* \author Pompei2
*/
bool onWindowActivated( const CEGUI::EventArgs &ea )
{
try {
const CEGUI::WindowEventArgs& we = static_cast<const CEGUI::WindowEventArgs&>(ea);
CEGUI::Window *pLastWin = pWinHistory.back( );

// We only work with FrameWindows.
if( !we.window->testClassName( CEGUI::FrameWindow::EventNamespace ) )
return true;

// If it is the same window as before, ignore it.
if( pLastWin == we.window )
return true;

if( pLastWin != CEGUI::System::getSingleton().getGUISheet() ) {
// If every time a window gets activated we make the last active window become
// transparent, this will result in all inactive windows being transparent.
pLastWin->setProperty( "Alpha", "0.25" );

// But we never make the root window transparent, as this would make all tooltips
// become transparent, and we don't want this !
}

// We need the active window to not inherit the transparence of its parents.
we.window->setProperty( "InheritsAlpha", "false" );

// Finally, we add the new window to the stack.

// One could also check if it's already present in the stack and if yes, just put it on the top.
// You would have to do this if you want to set the transparency depending on the window's position
// in the stack (see "Extending the effect").
pWinHistory.push_back( we.window );
} catch( CEGUI::Exception& e ) {
fprintf( stderr, "CEGUI error: %s\n", e.getMessage( ).c_str( ) );
return true;
}

return true;
}</code>

And onWindowClosed:
<code><cpp/>/// Called everytime a window gets closed.
/** This function is called by CEGUI just before a window gets closed.
*
* Currently, we use this function to activate the previous window
* when closing this one, as it's not done automatically by CEGUI.
*
* \param e The event arguments.
*
* \return Always true.
*
* \author Pompei2
*/
bool onWindowClosed( const CEGUI::EventArgs &ea )
{
try {
const CEGUI::WindowEventArgs& we = static_cast<const CEGUI::WindowEventArgs&>(ea);
CEGUI::Window *pLastWin = NULL;

// We only work with FrameWindows.
if( !we.window->testClassName( CEGUI::FrameWindow::EventNamespace ) )
return true;

// Delete the current window from the stack.
// CARE: std::list::remove removes ALL occurences of we.window from the stack !
// This is VERY important to know, as if you activate window A, then window B and then A again,
// the stack will contain A twice: {A,B,A}.
pWinHistory.remove( we.window );

// Now we get the window that was active before the current one:
pLastWin = m_pWinHistory.back( );

// re-activate it (like windos, linux, .. all do).
pLastWin->activate( );

// And set it to be opaque again.
// You could either do this here or you do this in the onWindowActivate function, the result is the same,
// as the call to CEGUI::Window::activate above results in onWindowActivate to be called.
pLastWin->setProperty( "Alpha", "1.0" );
} catch( CEGUI::Exception& e ) {
fprintf( stderr, "CEGUI error: %s\n", e.getMessage( ).c_str( ) );
return true;
}

return true;
}</code>

That's all.

One important thing you might not know yet, is that CEGUI DOESN'T activate a window that gets shown. you have to manually activate a window when you create it (and want it to be active, of course).

== Extending the effect ==
* You could also automatically activate a window as soon as it's shown. for this you could subscribe to the "a window gets shown" global event and then just call ea.window->activate( );
Edit: Hmm I tried this one but wasn't able to get it to work. If someone has success, please tell us how you did it in the forums.

* You could try to make the window's transparency degree dependent on it's position in the stack. That means the most recent windows get less transparent while the "oldest" windows get very transparent. To do this, just loop trough the stack - that would be a list - and set every window's transparency accordingly. Do this when a window gets active AND when a window gets closed. You would also need to never have the same window twice in the stack, as it would screw your results up.

--[[User:Pompei2|Pompei2]] 06:00, 6 May 2007 (PDT)

----
----
you can add more cool effects here.

Cool window effects

2007-07-02T09:19:15Z

Pompei2: /* The praxis (code) */

= Inactive windows become transparent =
'''WARNING ! As for now (02.07.2007), this code does make all your tooltips transparent, I'm working on a solution.'''

Please discuss this snippet within the [[http://www.cegui.org.uk/phpBB2/viewtopic.php?p=11786 cool window effects - Inactive windows become trans.]] thread.

Do you know about the [http://vizzzion.org/images/blog/composite.png cool effects that the composite extension can create] on linux ? There are many. I wanted to implement one into my game: make the [http://img337.imageshack.us/img337/9398/windowtransparencyue1.png inactive windows become transparent] and only the active one be 100% opaque. (see the links in this sentence for screenshots.) This effect can be interesting if you want your users to concentrate 100% on the active window and the inactive ones aren't important at this moment. But what if the user has to see two windows or more at the same time (and with full opacity) ? We'll see how to handle this.

== The theory ==
There is more then one way to achieve this, but I'll only present the one I chose. CEGUI has something that is called global events. These are events that are fired independently on the widget they apply to. I'll try with an example: sometimes you need to know when a button is clicked, no matter what button it is, you want to know it for EVERY button. This is what global events are for.

We'll subscribe to two global events: "a window gets activated" and "a window gets closed". When a window gets activated, we add it to a stack wich we use to keep track of the windows and the order they where activated. We also make the last active window become transparent. When a window gets closed, we remove it from the stack and activate the one that is on the top of the stack now. (that is the window that was active just before the one we just closed.)

== The praxis (code) ==
Now let's go ! First, we need to register callback functions to the two global events:
<code><cpp/>
CEGUI::GlobalEventSet::getSingleton( ).subscribeEvent( CEGUI::Window::EventNamespace + "/" + CEGUI::Window::EventActivated,
CEGUI::Event::Subscriber(&onWindowActivated) );
CEGUI::GlobalEventSet::getSingleton( ).subscribeEvent( CEGUI::Window::EventNamespace + "/" + CEGUI::Window::EventDestructionStarted,
CEGUI::Event::Subscriber(&onWindowClosed) );</code>

We also need a stack to keep track of the windows. I chose to use the std::list type instead of the std::stack, because we need to be able to either delete all references of one element or to search the stack. So here it is:
<code><cpp/>std::list<CEGUI::Window *> pWinHistory;</code>

Also, don't forget to put your root window just before setting it as the root window:
<code><cpp/>pWinHistory.push_back(pMyRootWindow);
CEGUI::System::getSingleton().setGUISheet(pMyRootWindow);
</code>

One thing you need to know about the root window is that you need an empty root window, containing one or more child windows that contain all GUI items. Your root window will never become transparent, thus you need an empty "container" root window.

And now we implement our two callback functions. I excessively commented the functions.

onWindowActivated:
<code><cpp/>/// Called everytime a window gets activated.
/** This function is called by CEGUI every time that a window gets the focus.
*
* Currently, we use this function to keep track of the order that windows where
* active, so when closing a window we can activate the last one, as this isn't
* done automatically by CEGUI.
*
* \param e The event arguments.
*
* \return Always true.
*
* \author Pompei2
*/
bool onWindowActivated( const CEGUI::EventArgs &ea )
{
try {
const CEGUI::WindowEventArgs& we = static_cast<const CEGUI::WindowEventArgs&>(ea);
CEGUI::Window *pLastWin = pWinHistory.back( );

// We only work with FrameWindows.
if( !we.window->testClassName( CEGUI::FrameWindow::EventNamespace ) )
return true;

// If it is the same window as before, ignore it.
if( pLastWin == we.window )
return true;

if( pLastWin != CEGUI::System::getSingleton().getGUISheet() ) {
// If every time a window gets activated we make the last active window become
// transparent, this will result in all inactive windows being transparent.
pLastWin->setProperty( "Alpha", "0.25" );

// But we never make the root window transparent, as this would make all tooltips
// become transparent, and we don't want this !
}

// We need the active window to not inherit the transparence of its parents.
we.window->setProperty( "InheritsAlpha", "false" );

// Finally, we add the new window to the stack.

// One could also check if it's already present in the stack and if yes, just put it on the top.
// You would have to do this if you want to set the transparency depending on the window's position
// in the stack (see "Extending the effect").
pWinHistory.push_back( we.window );
} catch( CEGUI::Exception& e ) {
fprintf( stderr, "CEGUI error: %s\n", e.getMessage( ).c_str( ) );
return true;
}

return true;
}</code>

And onWindowClosed:
<code><cpp/>/// Called everytime a window gets closed.
/** This function is called by CEGUI just before a window gets closed.
*
* Currently, we use this function to activate the previous window
* when closing this one, as it's not done automatically by CEGUI.
*
* \param e The event arguments.
*
* \return Always true.
*
* \author Pompei2
*/
bool onWindowClosed( const CEGUI::EventArgs &ea )
{
try {
const CEGUI::WindowEventArgs& we = static_cast<const CEGUI::WindowEventArgs&>(ea);
CEGUI::Window *pLastWin = NULL;

// We only work with FrameWindows.
if( !we.window->testClassName( CEGUI::FrameWindow::EventNamespace ) )
return true;

// Delete the current window from the stack.
// CARE: std::list::remove removes ALL occurences of we.window from the stack !
// This is VERY important to know, as if you activate window A, then window B and then A again,
// the stack will contain A twice: {A,B,A}.
pWinHistory.remove( we.window );

// Now we get the window that was active before the current one:
pLastWin = m_pWinHistory.back( );

// re-activate it (like windos, linux, .. all do).
pLastWin->activate( );

// And set it to be opaque again.
// You could either do this here or you do this in the onWindowActivate function, the result is the same,
// as the call to CEGUI::Window::activate above results in onWindowActivate to be called.
pLastWin->setProperty( "Alpha", "1.0" );
} catch( CEGUI::Exception& e ) {
fprintf( stderr, "CEGUI error: %s\n", e.getMessage( ).c_str( ) );
return true;
}

return true;
}</code>

That's all.

One important thing you might not know yet, is that CEGUI DOESN'T activate a window that gets shown. you have to manually activate a window when you create it (and want it to be active, of course).

== Extending the effect ==
* You could also automatically activate a window as soon as it's shown. for this you could subscribe to the "a window gets shown" global event and then just call ea.window->activate( );
Edit: Hmm I tried this one but wasn't able to get it to work. If someone has success, please tell us how you did it in the forums.

* You could try to make the window's transparency degree dependent on it's position in the stack. That means the most recent windows get less transparent while the "oldest" windows get very transparent. To do this, just loop trough the stack - that would be a list - and set every window's transparency accordingly. Do this when a window gets active AND when a window gets closed. You would also need to never have the same window twice in the stack, as it would screw your results up.

--[[User:Pompei2|Pompei2]] 06:00, 6 May 2007 (PDT)

----
----
you can add more cool effects here.

Cool window effects

2007-07-02T09:02:08Z

Pompei2: /* The praxis (code) */

= Inactive windows become transparent =
'''WARNING ! As for now (02.07.2007), this code does make all your tooltips transparent, I'm working on a solution.'''

Please discuss this snippet within the [[http://www.cegui.org.uk/phpBB2/viewtopic.php?p=11786 cool window effects - Inactive windows become trans.]] thread.

Do you know about the [http://vizzzion.org/images/blog/composite.png cool effects that the composite extension can create] on linux ? There are many. I wanted to implement one into my game: make the [http://img337.imageshack.us/img337/9398/windowtransparencyue1.png inactive windows become transparent] and only the active one be 100% opaque. (see the links in this sentence for screenshots.) This effect can be interesting if you want your users to concentrate 100% on the active window and the inactive ones aren't important at this moment. But what if the user has to see two windows or more at the same time (and with full opacity) ? We'll see how to handle this.

== The theory ==
There is more then one way to achieve this, but I'll only present the one I chose. CEGUI has something that is called global events. These are events that are fired independently on the widget they apply to. I'll try with an example: sometimes you need to know when a button is clicked, no matter what button it is, you want to know it for EVERY button. This is what global events are for.

We'll subscribe to two global events: "a window gets activated" and "a window gets closed". When a window gets activated, we add it to a stack wich we use to keep track of the windows and the order they where activated. We also make the last active window become transparent. When a window gets closed, we remove it from the stack and activate the one that is on the top of the stack now. (that is the window that was active just before the one we just closed.)

== The praxis (code) ==
Now let's go ! First, we need to register callback functions to the two global events:
<code><cpp/>
CEGUI::GlobalEventSet::getSingleton( ).subscribeEvent( CEGUI::Window::EventNamespace + "/" + CEGUI::Window::EventActivated,
CEGUI::Event::Subscriber(&onWindowActivated) );
CEGUI::GlobalEventSet::getSingleton( ).subscribeEvent( CEGUI::Window::EventNamespace + "/" + CEGUI::Window::EventDestructionStarted,
CEGUI::Event::Subscriber(&onWindowClosed) );</code>

We also need a stack to keep track of the windows. I chose to use the std::list type instead of the std::stack, because we need to be able to either delete all references of one element or to search the stack. So here it is:
<code><cpp/>std::list<CEGUI::Window *> pWinHistory;</code>

Also, don't forget to put your root window in it when you create it:
<code><cpp/>pWinHistory.push_back(pMyRootWindow);</code>

And now we implement our two callback functions. I excessively commented the functions.

onWindowActivated:
<code><cpp/>/// Called everytime a window gets activated.
/** This function is called by CEGUI every time that a window gets the focus.
*
* Currently, we use this function to keep track of the order that windows where
* active, so when closing a window we can activate the last one, as this isn't
* done automatically by CEGUI.
*
* \param e The event arguments.
*
* \return Always true.
*
* \author Pompei2
*/
bool onWindowActivated( const CEGUI::EventArgs &ea )
{
try {
const CEGUI::WindowEventArgs& we = static_cast<const CEGUI::WindowEventArgs&>(ea);
CEGUI::Window *pLastWin = pWinHistory.back( );

// We only work with FrameWindows.
if( !we.window->testClassName( CEGUI::FrameWindow::EventNamespace ) )
return true;

// If it is the same window as before, ignore it.
if( pLastWin == we.window )
return true;

// If every time a window gets activated we make the last active window become
// transparent, this will result in all inactive windows being transparent.
pLastWin->setProperty( "Alpha", "0.25" );

// We need the active window to not inherit the transparence of its parents.
we.window->setProperty( "InheritsAlpha", "false" );

// Finally, we add the new window to the stack.

// One could also check if it's already present in the stack and if yes, just put it on the top.
// You would have to do this if you want to set the transparency depending on the window's position
// in the stack (see "Extending the effect").
pWinHistory.push_back( we.window );
} catch( CEGUI::Exception& e ) {
fprintf( stderr, "CEGUI error: %s\n", e.getMessage( ).c_str( ) );
return true;
}

return true;
}</code>

And onWindowClosed:
<code><cpp/>/// Called everytime a window gets closed.
/** This function is called by CEGUI just before a window gets closed.
*
* Currently, we use this function to activate the previous window
* when closing this one, as it's not done automatically by CEGUI.
*
* \param e The event arguments.
*
* \return Always true.
*
* \author Pompei2
*/
bool onWindowClosed( const CEGUI::EventArgs &ea )
{
try {
const CEGUI::WindowEventArgs& we = static_cast<const CEGUI::WindowEventArgs&>(ea);
CEGUI::Window *pLastWin = NULL;

// We only work with FrameWindows.
if( !we.window->testClassName( CEGUI::FrameWindow::EventNamespace ) )
return true;

// Delete the current window from the stack.
// CARE: std::list::remove removes ALL occurences of we.window from the stack !
// This is VERY important to know, as if you activate window A, then window B and then A again,
// the stack will contain A twice: {A,B,A}.
pWinHistory.remove( we.window );

// Now we get the window that was active before the current one:
pLastWin = m_pWinHistory.back( );

// re-activate it (like windos, linux, .. all do).
pLastWin->activate( );

// And set it to be opaque again.
// You could either do this here or you do this in the onWindowActivate function, the result is the same,
// as the call to CEGUI::Window::activate above results in onWindowActivate to be called.
pLastWin->setProperty( "Alpha", "1.0" );
} catch( CEGUI::Exception& e ) {
fprintf( stderr, "CEGUI error: %s\n", e.getMessage( ).c_str( ) );
return true;
}

return true;
}</code>

That's all.

One important thing you might not know yet, is that CEGUI DOESN'T activate a window that gets shown. you have to manually activate a window when you create it (and want it to be active, of course).

== Extending the effect ==
* You could also automatically activate a window as soon as it's shown. for this you could subscribe to the "a window gets shown" global event and then just call ea.window->activate( );
Edit: Hmm I tried this one but wasn't able to get it to work. If someone has success, please tell us how you did it in the forums.

* You could try to make the window's transparency degree dependent on it's position in the stack. That means the most recent windows get less transparent while the "oldest" windows get very transparent. To do this, just loop trough the stack - that would be a list - and set every window's transparency accordingly. Do this when a window gets active AND when a window gets closed. You would also need to never have the same window twice in the stack, as it would screw your results up.

--[[User:Pompei2|Pompei2]] 06:00, 6 May 2007 (PDT)

----
----
you can add more cool effects here.

Cool window effects

2007-07-02T08:59:21Z

Pompei2:

= Inactive windows become transparent =
'''WARNING ! As for now (02.07.2007), this code does make all your tooltips transparent, I'm working on a solution.'''

Please discuss this snippet within the [[http://www.cegui.org.uk/phpBB2/viewtopic.php?p=11786 cool window effects - Inactive windows become trans.]] thread.

Do you know about the [http://vizzzion.org/images/blog/composite.png cool effects that the composite extension can create] on linux ? There are many. I wanted to implement one into my game: make the [http://img337.imageshack.us/img337/9398/windowtransparencyue1.png inactive windows become transparent] and only the active one be 100% opaque. (see the links in this sentence for screenshots.) This effect can be interesting if you want your users to concentrate 100% on the active window and the inactive ones aren't important at this moment. But what if the user has to see two windows or more at the same time (and with full opacity) ? We'll see how to handle this.

== The theory ==
There is more then one way to achieve this, but I'll only present the one I chose. CEGUI has something that is called global events. These are events that are fired independently on the widget they apply to. I'll try with an example: sometimes you need to know when a button is clicked, no matter what button it is, you want to know it for EVERY button. This is what global events are for.

We'll subscribe to two global events: "a window gets activated" and "a window gets closed". When a window gets activated, we add it to a stack wich we use to keep track of the windows and the order they where activated. We also make the last active window become transparent. When a window gets closed, we remove it from the stack and activate the one that is on the top of the stack now. (that is the window that was active just before the one we just closed.)

== The praxis (code) ==
Now let's go ! First, we need to register callback functions to the two global events:
<code><cpp/>
CEGUI::GlobalEventSet::getSingleton( ).subscribeEvent( CEGUI::Window::EventNamespace + "/" + CEGUI::Window::EventActivated,
CEGUI::Event::Subscriber(&onWindowActivated) );
CEGUI::GlobalEventSet::getSingleton( ).subscribeEvent( CEGUI::Window::EventNamespace + "/" + CEGUI::Window::EventDestructionStarted,
CEGUI::Event::Subscriber(&onWindowClosed) );</code>

We also need a stack to keep track of the windows. I chose to use the std::list type instead of the std::stack, because we need to be able to either delete all references of one element or to search the stack. So here it is:
<code><cpp/>std::list<CEGUI::Window *> pWinHistory;</code>

And now we implement our two callback functions. I excessively commented the functions.

onWindowActivated:
<code><cpp/>/// Called everytime a window gets activated.
/** This function is called by CEGUI every time that a window gets the focus.
*
* Currently, we use this function to keep track of the order that windows where
* active, so when closing a window we can activate the last one, as this isn't
* done automatically by CEGUI.
*
* \param e The event arguments.
*
* \return Always true.
*
* \author Pompei2
*/
bool onWindowActivated( const CEGUI::EventArgs &ea )
{
try {
const CEGUI::WindowEventArgs& we = static_cast<const CEGUI::WindowEventArgs&>(ea);
CEGUI::Window *pLastWin = pWinHistory.back( );

// We only work with FrameWindows.
if( !we.window->testClassName( CEGUI::FrameWindow::EventNamespace ) )
return true;

// If it is the same window as before, ignore it.
if( pLastWin == we.window )
return true;

// If every time a window gets activated we make the last active window become
// transparent, this will result in all inactive windows being transparent.
pLastWin->setProperty( "Alpha", "0.25" );

// We need the active window to not inherit the transparence of its parents.
we.window->setProperty( "InheritsAlpha", "false" );

// Finally, we add the new window to the stack.

// One could also check if it's already present in the stack and if yes, just put it on the top.
// You would have to do this if you want to set the transparency depending on the window's position
// in the stack (see "Extending the effect").
pWinHistory.push_back( we.window );
} catch( CEGUI::Exception& e ) {
fprintf( stderr, "CEGUI error: %s\n", e.getMessage( ).c_str( ) );
return true;
}

return true;
}</code>

And onWindowClosed:
<code><cpp/>/// Called everytime a window gets closed.
/** This function is called by CEGUI just before a window gets closed.
*
* Currently, we use this function to activate the previous window
* when closing this one, as it's not done automatically by CEGUI.
*
* \param e The event arguments.
*
* \return Always true.
*
* \author Pompei2
*/
bool onWindowClosed( const CEGUI::EventArgs &ea )
{
try {
const CEGUI::WindowEventArgs& we = static_cast<const CEGUI::WindowEventArgs&>(ea);
CEGUI::Window *pLastWin = NULL;

// We only work with FrameWindows.
if( !we.window->testClassName( CEGUI::FrameWindow::EventNamespace ) )
return true;

// Delete the current window from the stack.
// CARE: std::list::remove removes ALL occurences of we.window from the stack !
// This is VERY important to know, as if you activate window A, then window B and then A again,
// the stack will contain A twice: {A,B,A}.
pWinHistory.remove( we.window );

// Now we get the window that was active before the current one:
pLastWin = m_pWinHistory.back( );

// re-activate it (like windos, linux, .. all do).
pLastWin->activate( );

// And set it to be opaque again.
// You could either do this here or you do this in the onWindowActivate function, the result is the same,
// as the call to CEGUI::Window::activate above results in onWindowActivate to be called.
pLastWin->setProperty( "Alpha", "1.0" );
} catch( CEGUI::Exception& e ) {
fprintf( stderr, "CEGUI error: %s\n", e.getMessage( ).c_str( ) );
return true;
}

return true;
}</code>

That's all.

One important thing you might not know yet, is that CEGUI DOESN'T activate a window that gets shown. you have to manually activate a window when you create it (and want it to be active, of course).

== Extending the effect ==
* You could also automatically activate a window as soon as it's shown. for this you could subscribe to the "a window gets shown" global event and then just call ea.window->activate( );
Edit: Hmm I tried this one but wasn't able to get it to work. If someone has success, please tell us how you did it in the forums.

* You could try to make the window's transparency degree dependent on it's position in the stack. That means the most recent windows get less transparent while the "oldest" windows get very transparent. To do this, just loop trough the stack - that would be a list - and set every window's transparency accordingly. Do this when a window gets active AND when a window gets closed. You would also need to never have the same window twice in the stack, as it would screw your results up.

--[[User:Pompei2|Pompei2]] 06:00, 6 May 2007 (PDT)

----
----
you can add more cool effects here.

Cool window effects

2007-07-02T08:59:03Z

Pompei2:

= Inactive windows become transparent =
'''WARNING ! As for now (02.07.2007), this code does make all your tooltips transparent, I'm working on a solution.'''
Please discuss this snippet within the [[http://www.cegui.org.uk/phpBB2/viewtopic.php?p=11786 cool window effects - Inactive windows become trans.]] thread.

Do you know about the [http://vizzzion.org/images/blog/composite.png cool effects that the composite extension can create] on linux ? There are many. I wanted to implement one into my game: make the [http://img337.imageshack.us/img337/9398/windowtransparencyue1.png inactive windows become transparent] and only the active one be 100% opaque. (see the links in this sentence for screenshots.) This effect can be interesting if you want your users to concentrate 100% on the active window and the inactive ones aren't important at this moment. But what if the user has to see two windows or more at the same time (and with full opacity) ? We'll see how to handle this.

== The theory ==
There is more then one way to achieve this, but I'll only present the one I chose. CEGUI has something that is called global events. These are events that are fired independently on the widget they apply to. I'll try with an example: sometimes you need to know when a button is clicked, no matter what button it is, you want to know it for EVERY button. This is what global events are for.

We'll subscribe to two global events: "a window gets activated" and "a window gets closed". When a window gets activated, we add it to a stack wich we use to keep track of the windows and the order they where activated. We also make the last active window become transparent. When a window gets closed, we remove it from the stack and activate the one that is on the top of the stack now. (that is the window that was active just before the one we just closed.)

== The praxis (code) ==
Now let's go ! First, we need to register callback functions to the two global events:
<code><cpp/>
CEGUI::GlobalEventSet::getSingleton( ).subscribeEvent( CEGUI::Window::EventNamespace + "/" + CEGUI::Window::EventActivated,
CEGUI::Event::Subscriber(&onWindowActivated) );
CEGUI::GlobalEventSet::getSingleton( ).subscribeEvent( CEGUI::Window::EventNamespace + "/" + CEGUI::Window::EventDestructionStarted,
CEGUI::Event::Subscriber(&onWindowClosed) );</code>

We also need a stack to keep track of the windows. I chose to use the std::list type instead of the std::stack, because we need to be able to either delete all references of one element or to search the stack. So here it is:
<code><cpp/>std::list<CEGUI::Window *> pWinHistory;</code>

And now we implement our two callback functions. I excessively commented the functions.

onWindowActivated:
<code><cpp/>/// Called everytime a window gets activated.
/** This function is called by CEGUI every time that a window gets the focus.
*
* Currently, we use this function to keep track of the order that windows where
* active, so when closing a window we can activate the last one, as this isn't
* done automatically by CEGUI.
*
* \param e The event arguments.
*
* \return Always true.
*
* \author Pompei2
*/
bool onWindowActivated( const CEGUI::EventArgs &ea )
{
try {
const CEGUI::WindowEventArgs& we = static_cast<const CEGUI::WindowEventArgs&>(ea);
CEGUI::Window *pLastWin = pWinHistory.back( );

// We only work with FrameWindows.
if( !we.window->testClassName( CEGUI::FrameWindow::EventNamespace ) )
return true;

// If it is the same window as before, ignore it.
if( pLastWin == we.window )
return true;

// If every time a window gets activated we make the last active window become
// transparent, this will result in all inactive windows being transparent.
pLastWin->setProperty( "Alpha", "0.25" );

// We need the active window to not inherit the transparence of its parents.
we.window->setProperty( "InheritsAlpha", "false" );

// Finally, we add the new window to the stack.

// One could also check if it's already present in the stack and if yes, just put it on the top.
// You would have to do this if you want to set the transparency depending on the window's position
// in the stack (see "Extending the effect").
pWinHistory.push_back( we.window );
} catch( CEGUI::Exception& e ) {
fprintf( stderr, "CEGUI error: %s\n", e.getMessage( ).c_str( ) );
return true;
}

return true;
}</code>

And onWindowClosed:
<code><cpp/>/// Called everytime a window gets closed.
/** This function is called by CEGUI just before a window gets closed.
*
* Currently, we use this function to activate the previous window
* when closing this one, as it's not done automatically by CEGUI.
*
* \param e The event arguments.
*
* \return Always true.
*
* \author Pompei2
*/
bool onWindowClosed( const CEGUI::EventArgs &ea )
{
try {
const CEGUI::WindowEventArgs& we = static_cast<const CEGUI::WindowEventArgs&>(ea);
CEGUI::Window *pLastWin = NULL;

// We only work with FrameWindows.
if( !we.window->testClassName( CEGUI::FrameWindow::EventNamespace ) )
return true;

// Delete the current window from the stack.
// CARE: std::list::remove removes ALL occurences of we.window from the stack !
// This is VERY important to know, as if you activate window A, then window B and then A again,
// the stack will contain A twice: {A,B,A}.
pWinHistory.remove( we.window );

// Now we get the window that was active before the current one:
pLastWin = m_pWinHistory.back( );

// re-activate it (like windos, linux, .. all do).
pLastWin->activate( );

// And set it to be opaque again.
// You could either do this here or you do this in the onWindowActivate function, the result is the same,
// as the call to CEGUI::Window::activate above results in onWindowActivate to be called.
pLastWin->setProperty( "Alpha", "1.0" );
} catch( CEGUI::Exception& e ) {
fprintf( stderr, "CEGUI error: %s\n", e.getMessage( ).c_str( ) );
return true;
}

return true;
}</code>

That's all.

One important thing you might not know yet, is that CEGUI DOESN'T activate a window that gets shown. you have to manually activate a window when you create it (and want it to be active, of course).

== Extending the effect ==
* You could also automatically activate a window as soon as it's shown. for this you could subscribe to the "a window gets shown" global event and then just call ea.window->activate( );
Edit: Hmm I tried this one but wasn't able to get it to work. If someone has success, please tell us how you did it in the forums.

* You could try to make the window's transparency degree dependent on it's position in the stack. That means the most recent windows get less transparent while the "oldest" windows get very transparent. To do this, just loop trough the stack - that would be a list - and set every window's transparency accordingly. Do this when a window gets active AND when a window gets closed. You would also need to never have the same window twice in the stack, as it would screw your results up.

--[[User:Pompei2|Pompei2]] 06:00, 6 May 2007 (PDT)

----
----
you can add more cool effects here.

Using CEGUI with SDL and OpenGL

2007-05-30T10:40:17Z

Pompei2: /* Injecting Input */

[http://www.libsdl.org SDL (Simple DirectMedia Layer)] is an excellent library for writing portable games and other multimedia applications, but as it is a low-level library, it has no native support for GUI interfaces.

When using [http://www.opengl.org OpenGL] for rendering, using CEGUI with SDL is not hard.

I'll assume that you've read the imbiciles tutorials, and have used SDL with OpenGL.
And know C / C++ ...

=== Initialisation ===
Before we can do anything, we need to initialise our libraries.
First SDL:

<code><cpp/>
if (SDL_Init(SDL_INIT_VIDEO)<0)
{
fprintf(stderr, "Unable to initialise SDL: %s", SDL_GetError());
exit(0);
}
</code>

Here we initialise SDL with video support. We need this for CEGUI.
O.K. now SDL is ready to go. So let's fire up OpenGL:

<code><cpp/>
if (SDL_SetVideoMode(800,600,0,SDL_OPENGL)==NULL)
{
fprintf(stderr, "Unable to set OpenGL videomode: %s", SDL_GetError());
SDL_Quit();
exit(0);
}
</code>

Now OpenGL is ready. But we still need to set a decent configuration:

<code><cpp/>
glEnable(GL_CULL_FACE);
glDisable(GL_FOG);
glClearColor(0.0f,0.0f,0.0f,1.0f);
glViewport(0,0, 800,600);
</code>

The OpenGL renderer that comes with CEGUI sets the matrices itself, so if you're using CEGUI for all your rendering needs this would be fine. Normally you would want the normal perspective projection setup though:

<code><cpp/>
glMatrixMode(GL_PROJECTION);
glLoadIdentity();
gluPerspective(45.0, 800.0/600.0, 0.1,100.0);
glMatrixMode(GL_MODELVIEW);
glLoadIdentity();
</code>

SDL and OpenGL are now both ready for action. So it's time to initialise CEGUI.
First we need the renderer.

<code><cpp/>
#include "renderers/OpenGLGUIRenderer/openglrenderer.h"
</code>

It must be created before starting CEGUI.

<code><cpp/>
CEGUI::OpenGLRenderer* renderer = new CEGUI::OpenGLRenderer(0,800,600);
</code>

Then the CEGUI::System must be initialised:

<code><cpp/>
new CEGUI::System(renderer);
</code>

Remember that you have to load a widget set, set the mouse cursor and a default font before CEGUI is completely ready. This is described in the other tutorials.

By default the SDL cursor is displayed, so we'll remove that:

<code><cpp/>
SDL_ShowCursor(SDL_DISABLE);
</code>

As keypress characters needs to be injected into CEGUI, we activate unicode translation for SDL key events:

<code><cpp/>
SDL_EnableUNICODE(1);
</code>

This makes it alot easier as we don't have to worry about modifier keys and keyboard layouts ourselves. More about this later on...

Key repeat is a nice feature for the text input widgets in CEGUI, so we use SDL to generate them:

<code><cpp/>
SDL_EnableKeyRepeat(SDL_DEFAULT_REPEAT_DELAY, SDL_DEFAULT_REPEAT_INTERVAL);
</code>

Everything is ready now, and we can start the main loop :)

=== The Main Loop ===
To make it all happen, we use a simple main loop that just keeps pushing on those frames:

<code><cpp/>
void main_loop()
{
bool must_quit = false;

// get "run-time" in seconds
double last_time_pulse = 0.001*static_cast<double>(SDL_GetTicks());

while (!must_quit)
{
inject_input(must_quit);
inject_time_pulse(last_time_pulse);
render_gui();
}
}
</code>

This function will run the main loop until the ''bool'' value ''must_quit'' becomes ''true''. In this tutorial this will happen when the user clicks the close button provided by the window manager.

The ''double'' value ''last_time_pulse'' holds the time of the latest time pulse injection. More about this later.

Each function in the ''while'' loop will be described below.

There are endless ways of making your main loop. I took a simple approach to ease writing this tutorial.

=== Injecting Input ===
When the user press or release keyboard or mouse buttons, we need to tell CEGUI about it, for this we use the injection functions of ''CEGUI::System''.

Here is what our inject_input function looks like:

<code><cpp/>
void inject_input(bool& must_quit)
{
SDL_Event e;

// go through all available events
while (SDL_PollEvent(&e))
{
// we use a switch to determine the event type
switch (e.type)
{
// mouse motion handler
case SDL_MOUSEMOTION:
// we inject the mouse position directly.
CEGUI::System::getSingleton().injectMousePosition(
static_cast<float>(e.motion.x),
static_cast<float>(e.motion.y)
);
break;

// mouse down handler
case SDL_MOUSEBUTTONDOWN:
// let a special function handle the mouse button down event
handle_mouse_down(e.button.button);
break;

// mouse up handler
case SDL_MOUSEBUTTONUP:
// let a special function handle the mouse button up event
handle_mouse_up(e.button.button);
break;

// key down
case SDL_KEYDOWN:
// to tell CEGUI that a key was pressed, we inject the scancode.
CEGUI::System::getSingleton().injectKeyDown(e.key.keysym.scancode);

// as for the character it's a litte more complicated. we'll use for translated unicode value.
// this is described in more detail below.
if ((e.key.keysym.unicode != 0)
{
CEGUI::System::getSingleton().injectChar(e.key.keysym.unicode);
}
break;

// key up
case SDL_KEYUP:
// like before we inject the scancode directly.
CEGUI::System::getSingleton().injectKeyUp(e.key.keysym.scancode);
break;

// WM quit event occured
case SDL_QUIT:
must_quit = true;
break;

}

}

}
</code>

First I'll explain the events that get handled directly in the ''inject_input'' function.

'''Mouse Motion''':

<code><cpp/>
// we inject the mouse position directly.
CEGUI::System::getSingleton().injectMousePosition(
static_cast<float>(e.motion.x),
static_cast<float>(e.motion.y)
);
</code>

There is nothing special here. Like stated in the comment the mouse position is just injected directly.

There are two ways of injecting mouse motion. One where you inject how much the cursor moved, and one where you inject the mouse cursor position. The last one is failsafe.
Then first one only works correctly in fullscreen mode, or with input grabbed. The reason for this is that in regular windowed mode, the mouse can be moved outside the application window, and during this time no mouse motion event are generated. So if we enter the window at another position, the real mousecursor and CEGUI's mouse cursor will be offset, which will break mouse usage.

'''Key Down'''<br />
This event takes a little more work. CEGUI requires that key characters (the printable character the key represents) are injected alongside key codes.

<code><cpp/>
// to tell CEGUI that a key was pressed, we inject the scancode.
CEGUI::System::getSingleton().injectKeyDown(e.key.keysym.scancode);
</code>

Luckily the key code is just the SDL scancode, so we inject that directly. (This only seems to be true on windows. On other platforms you will need to use a translation function. One can be found here [[SDL to CEGUI keytable]])

<code><cpp/>
// as for the character it's a litte more complicated. we'll use for translated unicode value.
// this is described in more detail below.
if (e.key.keysym.unicode != 0)
{
CEGUI::System::getSingleton().injectChar(e.key.keysym.unicode);
}
</code>

Instead of formatting the keypress ourselves, we let SDL do it for us. We could check if we actually got a valid ASCII code, but we want support for local characters as well, so we won't do that. For more information, take a look at the SDL documentation for this feature. [http://www.libsdl.org/cgi/docwiki.cgi/SDL_5fkeysym SDL_keysym].

'''Key Up'''<br />
This one is simple. Only the keycode need to injected. So we just use the scancode directly (As with KeyDown you will need to use a translation function for non Windows platforms. Check KeyDown above for more info):

<code><cpp/>
// like before we inject the scancode directly.
CEGUI::System::getSingleton().injectKeyUp(e.key.keysym.scancode);
</code>

'''Mouse Button Down and Mouse Wheel'''<br />
CEGUI and SDL are a little different when it comes to mouse button and mouse wheel events. So a little conversion is necessary. Here's the ''handle_mouse_down'' function that gets called when a mouse button down event occurs in SDL. It takes one parameter, a ''Uint8'' describing the mouse button that was pressed.

<code><cpp/>
void handle_mouse_down(Uint8 button)
{
switch ( button )
{
// handle real mouse buttons
case SDL_BUTTON_LEFT:
CEGUI::System::getSingleton().injectMouseButtonDown(CEGUI::LeftButton);
break;
case SDL_BUTTON_MIDDLE:
CEGUI::System::getSingleton().injectMouseButtonDown(CEGUI::MiddleButton);
break;
case SDL_BUTTON_RIGHT:
CEGUI::System::getSingleton().injectMouseButtonDown(CEGUI::RightButton);
break;

// handle the mouse wheel
case SDL_BUTTON_WHEELDOWN:
CEGUI::System::getSingleton().injectMouseWheelChange( -1 );
break;
case SDL_BUTTON_WHEELUP:
CEGUI::System::getSingleton().injectMouseWheelChange( +1 );
break;
}
}
</code>

I chose a very "manual" conversion, but it works fine. Everything should be pretty self-explainatory.
As you can see mouse wheel events are emitted as mouse button down events in SDL.

'''Mouse Button Up'''<br />
The mouse button up event is handled very much like the mouse button down event, except there are no mousewheel release events.
Like ''handle_mouse_down'' it takes one parameter, a ''Uint8'' describing the mouse button that was released:

<code><cpp/>
void handle_mouse_up(Uint8 button)
{
switch ( button )
{
case SDL_BUTTON_LEFT:
CEGUI::System::getSingleton().injectMouseButtonUp(CEGUI::LeftButton);
break;
case SDL_BUTTON_MIDDLE:
CEGUI::System::getSingleton().injectMouseButtonUp(CEGUI::MiddleButton);
break;
case SDL_BUTTON_RIGHT:
CEGUI::System::getSingleton().injectMouseButtonUp(CEGUI::RightButton);
break;
}
}
</code>

=== Time Pulses ===
SDL has a built-in millisecond counter which we will use for this example. There are other ways to use timers with SDL, but I chose this approach as it is simple to use, and provides decent precision.

Remember in the main loop where we stored the current "run-time" in seconds ? This value will be passed as a reference to ''inject_time_pulse'' function which in turn will set a new value to it.

CEGUI's interface for injecting time pulses requires that you pass the time in seconds that has passed since the last time pulse injection. Let's take a look at the function:

<code><cpp/>
void inject_time_pulse(double& last_time_pulse)
{
// get current "run-time" in seconds
double t = 0.001*SDL_GetTicks();

// inject the time that passed since the last call
CEGUI::System::getSingleton().injectTimePulse( float(t-last_time_pulse) );

// store the new time as the last time
last_time_pulse = t;
}
</code>

* The first line gets the actual "run-time" when called.
* The second line injects the time pulse as the difference between the current time and the last time.
* The third line stores the current time as the last time a time pulse was injected.

This will work for about 47 days... After that the counter wraps to zero and it breaks (a single insanely invalid timepulse will be injected).
I'll leave it up to you to fix that if it's a problem.

=== Rendering ===
Now all that's left is renderingthe GUI.

<code><cpp/>
void render_gui()
{
// clear the colour buffer
glClear( GL_COLOR_BUFFER_BIT );

// render the GUI :)
CEGUI::System::getSingleton().renderGUI();

// Update the screen
SDL_GL_SwapBuffers();
}
</code>

The line:

<code><cpp/>
CEGUI::System::getSingleton().renderGUI();
</code>

does all the CEGUI magic and sets OpenGL state itself. As long as the viewport is setup, it will render the GUI.

=== Error Handling ===
The neat C++ architecture of CEGUI suggests that C++ exceptions are used for error handling. This is completely true.
Whenever an error occurs, a sub-class of ''CEGUI::Exception'' is thrown.

There are many scenarios where an exception can be thrown. And whether or not these should be considered fatal depends on the application. To make sure you catch the CEGUI exceptions a regular ''try'' block is used. Like so:

<code><cpp/>
try
{
// do some cegui code
}
catch (CEGUI::Exception& e)
{
fprintf(stderr,"CEGUI Exception occured: %s", e.getMessage().c_str());
// you could quit here
}
</code>

This should provide you with the basic steps needed to get interactive with CEGUI in your SDL application.
Have fun.

=== The Code ===
To compile under linux:
<code>gcc teste.cpp -I/usr/include/CEGUI/ -lSDL -lGL -lGLU -lCEGUIBase -lCEGUIOpenGLRenderer</code>

This code uses release 0.5.0 of CEGUI.
<code><cpp/>
/*
* Adapted by: Johnny Souza - johnnysouza.js@gmail.com
* Date: 19/01/07 17:00
* Description: Using CEGUI with SDL and OpenGL
*/

#include <stdio.h>
#include <stdlib.h>

#include <SDL/SDL.h>

#include <CEGUI.h>
/* for release 0.4.X use:
* #include <renderers/OpenGLGUIRenderer/openglrenderer.h>
*/
#include <RendererModules/OpenGLGUIRenderer/openglrenderer.h>

#include <GL/gl.h>
#include <GL/glu.h>

void handle_mouse_down(Uint8 button)
{
switch ( button ) {
case SDL_BUTTON_LEFT:
CEGUI::System::getSingleton().injectMouseButtonDown(CEGUI::LeftButton);
break;
case SDL_BUTTON_MIDDLE:
CEGUI::System::getSingleton().injectMouseButtonDown(CEGUI::MiddleButton);
break;
case SDL_BUTTON_RIGHT:
CEGUI::System::getSingleton().injectMouseButtonDown(CEGUI::RightButton);
break;

case SDL_BUTTON_WHEELDOWN:
CEGUI::System::getSingleton().injectMouseWheelChange( -1 );
break;
case SDL_BUTTON_WHEELUP:
CEGUI::System::getSingleton().injectMouseWheelChange( +1 );
break;
}
}

void handle_mouse_up(Uint8 button)
{
switch ( button )
{
case SDL_BUTTON_LEFT:
CEGUI::System::getSingleton().injectMouseButtonUp(CEGUI::LeftButton);
break;
case SDL_BUTTON_MIDDLE:
CEGUI::System::getSingleton().injectMouseButtonUp(CEGUI::MiddleButton);
break;
case SDL_BUTTON_RIGHT:
CEGUI::System::getSingleton().injectMouseButtonUp(CEGUI::RightButton);
break;
}
}

void inject_input (bool & must_quit)
{
SDL_Event e;
/* go through all available events */
while (SDL_PollEvent(&e)) {
/* we use a switch to determine the event type */
switch (e.type) {
/* mouse motion handler */
case SDL_MOUSEMOTION:
/* we inject the mouse position directly. */
CEGUI::System::getSingleton().injectMousePosition(static_cast<float>(e.motion.x),static_cast<float>(e.motion.y));
break;

/* mouse down handler */
case SDL_MOUSEBUTTONDOWN:
/* let a special function handle the mouse button down event */
handle_mouse_down (e.button.button);
break;

/* mouse up handler */
case SDL_MOUSEBUTTONUP:
/* let a special function handle the mouse button up event */
handle_mouse_up (e.button.button);
break;

/* key down */
case SDL_KEYDOWN:
/* to tell CEGUI that a key was pressed, we inject the scancode. */
CEGUI::System::getSingleton().injectKeyDown(e.key.keysym.scancode);
/* as for the character it's a litte more complicated.
* we'll use for translated unicode value.
* this is described in more detail below.
*/
if ((e.key.keysym.unicode & 0xFF80) == 0) {
CEGUI::System::getSingleton().injectChar(e.key.keysym.unicode & 0x7F);
}
break;

/* key up */
case SDL_KEYUP:
/* like before we inject the scancode directly. */
CEGUI::System::getSingleton().injectKeyUp(e.key.keysym.scancode);
break;

/* WM quit event occured */
case SDL_QUIT:
must_quit = true;
break;
}
}
}

void inject_time_pulse(double& last_time_pulse)
{
/* get current "run-time" in seconds */
double t = 0.001*SDL_GetTicks();
/* inject the time that passed since the last call */
CEGUI::System::getSingleton().injectTimePulse( float(t-last_time_pulse) );
/* store the new time as the last time */
last_time_pulse = t;
}

void render_gui()
{
/* clear the colour buffer */
glClear( GL_COLOR_BUFFER_BIT );
/* render the GUI :) */
CEGUI::System::getSingleton().renderGUI();
/* Update the screen */
SDL_GL_SwapBuffers();
}

void main_loop ()
{
bool must_quit = false;
/* get "run-time" in seconds */
double last_time_pulse = 0.001*static_cast<double>(SDL_GetTicks());
while (!must_quit) {
inject_input (must_quit);
inject_time_pulse (last_time_pulse);
render_gui ();
}
}

int main (int argc, char **argv)
{
SDL_Surface * screen;
atexit (SDL_Quit);
SDL_Init (SDL_INIT_VIDEO);
screen = SDL_SetVideoMode (600, 480, 0, SDL_OPENGL);
if (screen == NULL) {
/* Se ainda não der, desiste! */
fprintf (stderr, "Impossível ajustar ao vídeo: %s\n", SDL_GetError ());
exit (1);
}
CEGUI::OpenGLRenderer * renderer = new CEGUI::OpenGLRenderer (0, 600, 480);
new CEGUI::System (renderer);
SDL_ShowCursor (SDL_DISABLE);
SDL_EnableUNICODE (1);
SDL_EnableKeyRepeat (SDL_DEFAULT_REPEAT_DELAY, SDL_DEFAULT_REPEAT_INTERVAL);
main_loop();
}
</code>

--[[User:Lindquist|Lindquist]] 16:21, 8 May 2005 (BST)

Cool window effects

2007-05-06T13:01:19Z

Pompei2: /* Inactive windows become transparent */

= Inactive windows become transparent =
Please discuss this snippet within the [[http://www.cegui.org.uk/phpBB2/viewtopic.php?p=11786 cool window effects - Inactive windows become trans.]] thread.

Do you know about the [http://vizzzion.org/images/blog/composite.png cool effects that the composite extension can create] on linux ? There are many. I wanted to implement one into my game: make the [http://img337.imageshack.us/img337/9398/windowtransparencyue1.png inactive windows become transparent] and only the active one be 100% opaque. (see the links in this sentence for screenshots.) This effect can be interesting if you want your users to concentrate 100% on the active window and the inactive ones aren't important at this moment. But what if the user has to see two windows or more at the same time (and with full opacity) ? We'll see how to handle this.

== The theory ==
There is more then one way to achieve this, but I'll only present the one I chose. CEGUI has something that is called global events. These are events that are fired independently on the widget they apply to. I'll try with an example: sometimes you need to know when a button is clicked, no matter what button it is, you want to know it for EVERY button. This is what global events are for.

We'll subscribe to two global events: "a window gets activated" and "a window gets closed". When a window gets activated, we add it to a stack wich we use to keep track of the windows and the order they where activated. We also make the last active window become transparent. When a window gets closed, we remove it from the stack and activate the one that is on the top of the stack now. (that is the window that was active just before the one we just closed.)

== The praxis (code) ==
Now let's go ! First, we need to register callback functions to the two global events:
<code><cpp/>
CEGUI::GlobalEventSet::getSingleton( ).subscribeEvent( CEGUI::Window::EventNamespace + "/" + CEGUI::Window::EventActivated,
CEGUI::Event::Subscriber(&onWindowActivated) );
CEGUI::GlobalEventSet::getSingleton( ).subscribeEvent( CEGUI::Window::EventNamespace + "/" + CEGUI::Window::EventDestructionStarted,
CEGUI::Event::Subscriber(&onWindowClosed) );</code>

We also need a stack to keep track of the windows. I chose to use the std::list type instead of the std::stack, because we need to be able to either delete all references of one element or to search the stack. So here it is:
<code><cpp/>std::list<CEGUI::Window *> pWinHistory;</code>

And now we implement our two callback functions. I excessively commented the functions.

onWindowActivated:
<code><cpp/>/// Called everytime a window gets activated.
/** This function is called by CEGUI every time that a window gets the focus.
*
* Currently, we use this function to keep track of the order that windows where
* active, so when closing a window we can activate the last one, as this isn't
* done automatically by CEGUI.
*
* \param e The event arguments.
*
* \return Always true.
*
* \author Pompei2
*/
bool onWindowActivated( const CEGUI::EventArgs &ea )
{
try {
const CEGUI::WindowEventArgs& we = static_cast<const CEGUI::WindowEventArgs&>(ea);
CEGUI::Window *pLastWin = pWinHistory.back( );

// We only work with FrameWindows.
if( !we.window->testClassName( CEGUI::FrameWindow::EventNamespace ) )
return true;

// If it is the same window as before, ignore it.
if( pLastWin == we.window )
return true;

// If every time a window gets activated we make the last active window become
// transparent, this will result in all inactive windows being transparent.
pLastWin->setProperty( "Alpha", "0.25" );

// We need the active window to not inherit the transparence of its parents.
we.window->setProperty( "InheritsAlpha", "false" );

// Finally, we add the new window to the stack.

// One could also check if it's already present in the stack and if yes, just put it on the top.
// You would have to do this if you want to set the transparency depending on the window's position
// in the stack (see "Extending the effect").
pWinHistory.push_back( we.window );
} catch( CEGUI::Exception& e ) {
fprintf( stderr, "CEGUI error: %s\n", e.getMessage( ).c_str( ) );
return true;
}

return true;
}</code>

And onWindowClosed:
<code><cpp/>/// Called everytime a window gets closed.
/** This function is called by CEGUI just before a window gets closed.
*
* Currently, we use this function to activate the previous window
* when closing this one, as it's not done automatically by CEGUI.
*
* \param e The event arguments.
*
* \return Always true.
*
* \author Pompei2
*/
bool onWindowClosed( const CEGUI::EventArgs &ea )
{
try {
const CEGUI::WindowEventArgs& we = static_cast<const CEGUI::WindowEventArgs&>(ea);
CEGUI::Window *pLastWin = NULL;

// We only work with FrameWindows.
if( !we.window->testClassName( CEGUI::FrameWindow::EventNamespace ) )
return true;

// Delete the current window from the stack.
// CARE: std::list::remove removes ALL occurences of we.window from the stack !
// This is VERY important to know, as if you activate window A, then window B and then A again,
// the stack will contain A twice: {A,B,A}.
pWinHistory.remove( we.window );

// Now we get the window that was active before the current one:
pLastWin = m_pWinHistory.back( );

// re-activate it (like windos, linux, .. all do).
pLastWin->activate( );

// And set it to be opaque again.
// You could either do this here or you do this in the onWindowActivate function, the result is the same,
// as the call to CEGUI::Window::activate above results in onWindowActivate to be called.
pLastWin->setProperty( "Alpha", "1.0" );
} catch( CEGUI::Exception& e ) {
fprintf( stderr, "CEGUI error: %s\n", e.getMessage( ).c_str( ) );
return true;
}

return true;
}</code>

That's all.

One important thing you might not know yet, is that CEGUI DOESN'T activate a window that gets shown. you have to manually activate a window when you create it (and want it to be active, of course).

== Extending the effect ==
* You could also automatically activate a window as soon as it's shown. for this you could subscribe to the "a window gets shown" global event and then just call ea.window->activate( );
Edit: Hmm I tried this one but wasn't able to get it to work. If someone has success, please tell us how you did it in the forums.

* You could try to make the window's transparency degree dependent on it's position in the stack. That means the most recent windows get less transparent while the "oldest" windows get very transparent. To do this, just loop trough the stack - that would be a list - and set every window's transparency accordingly. Do this when a window gets active AND when a window gets closed. You would also need to never have the same window twice in the stack, as it would screw your results up.

--[[User:Pompei2|Pompei2]] 06:00, 6 May 2007 (PDT)

----
----
you can add more cool effects here.

Cool window effects

2007-05-06T13:00:17Z

Pompei2:

= Inactive windows become transparent =
Please discuss this snippet within the [[cool window effects - Inactive windows become trans.]] thread.

Do you know about the [http://vizzzion.org/images/blog/composite.png cool effects that the composite extension can create] on linux ? There are many. I wanted to implement one into my game: make the [http://img337.imageshack.us/img337/9398/windowtransparencyue1.png inactive windows become transparent] and only the active one be 100% opaque. (see the links in this sentence for screenshots.) This effect can be interesting if you want your users to concentrate 100% on the active window and the inactive ones aren't important at this moment. But what if the user has to see two windows or more at the same time (and with full opacity) ? We'll see how to handle this.

== The theory ==
There is more then one way to achieve this, but I'll only present the one I chose. CEGUI has something that is called global events. These are events that are fired independently on the widget they apply to. I'll try with an example: sometimes you need to know when a button is clicked, no matter what button it is, you want to know it for EVERY button. This is what global events are for.

We'll subscribe to two global events: "a window gets activated" and "a window gets closed". When a window gets activated, we add it to a stack wich we use to keep track of the windows and the order they where activated. We also make the last active window become transparent. When a window gets closed, we remove it from the stack and activate the one that is on the top of the stack now. (that is the window that was active just before the one we just closed.)

== The praxis (code) ==
Now let's go ! First, we need to register callback functions to the two global events:
<code><cpp/>
CEGUI::GlobalEventSet::getSingleton( ).subscribeEvent( CEGUI::Window::EventNamespace + "/" + CEGUI::Window::EventActivated,
CEGUI::Event::Subscriber(&onWindowActivated) );
CEGUI::GlobalEventSet::getSingleton( ).subscribeEvent( CEGUI::Window::EventNamespace + "/" + CEGUI::Window::EventDestructionStarted,
CEGUI::Event::Subscriber(&onWindowClosed) );</code>

We also need a stack to keep track of the windows. I chose to use the std::list type instead of the std::stack, because we need to be able to either delete all references of one element or to search the stack. So here it is:
<code><cpp/>std::list<CEGUI::Window *> pWinHistory;</code>

And now we implement our two callback functions. I excessively commented the functions.

onWindowActivated:
<code><cpp/>/// Called everytime a window gets activated.
/** This function is called by CEGUI every time that a window gets the focus.
*
* Currently, we use this function to keep track of the order that windows where
* active, so when closing a window we can activate the last one, as this isn't
* done automatically by CEGUI.
*
* \param e The event arguments.
*
* \return Always true.
*
* \author Pompei2
*/
bool onWindowActivated( const CEGUI::EventArgs &ea )
{
try {
const CEGUI::WindowEventArgs& we = static_cast<const CEGUI::WindowEventArgs&>(ea);
CEGUI::Window *pLastWin = pWinHistory.back( );

// We only work with FrameWindows.
if( !we.window->testClassName( CEGUI::FrameWindow::EventNamespace ) )
return true;

// If it is the same window as before, ignore it.
if( pLastWin == we.window )
return true;

// If every time a window gets activated we make the last active window become
// transparent, this will result in all inactive windows being transparent.
pLastWin->setProperty( "Alpha", "0.25" );

// We need the active window to not inherit the transparence of its parents.
we.window->setProperty( "InheritsAlpha", "false" );

// Finally, we add the new window to the stack.

// One could also check if it's already present in the stack and if yes, just put it on the top.
// You would have to do this if you want to set the transparency depending on the window's position
// in the stack (see "Extending the effect").
pWinHistory.push_back( we.window );
} catch( CEGUI::Exception& e ) {
fprintf( stderr, "CEGUI error: %s\n", e.getMessage( ).c_str( ) );
return true;
}

return true;
}</code>

And onWindowClosed:
<code><cpp/>/// Called everytime a window gets closed.
/** This function is called by CEGUI just before a window gets closed.
*
* Currently, we use this function to activate the previous window
* when closing this one, as it's not done automatically by CEGUI.
*
* \param e The event arguments.
*
* \return Always true.
*
* \author Pompei2
*/
bool onWindowClosed( const CEGUI::EventArgs &ea )
{
try {
const CEGUI::WindowEventArgs& we = static_cast<const CEGUI::WindowEventArgs&>(ea);
CEGUI::Window *pLastWin = NULL;

// We only work with FrameWindows.
if( !we.window->testClassName( CEGUI::FrameWindow::EventNamespace ) )
return true;

// Delete the current window from the stack.
// CARE: std::list::remove removes ALL occurences of we.window from the stack !
// This is VERY important to know, as if you activate window A, then window B and then A again,
// the stack will contain A twice: {A,B,A}.
pWinHistory.remove( we.window );

// Now we get the window that was active before the current one:
pLastWin = m_pWinHistory.back( );

// re-activate it (like windos, linux, .. all do).
pLastWin->activate( );

// And set it to be opaque again.
// You could either do this here or you do this in the onWindowActivate function, the result is the same,
// as the call to CEGUI::Window::activate above results in onWindowActivate to be called.
pLastWin->setProperty( "Alpha", "1.0" );
} catch( CEGUI::Exception& e ) {
fprintf( stderr, "CEGUI error: %s\n", e.getMessage( ).c_str( ) );
return true;
}

return true;
}</code>

That's all.

One important thing you might not know yet, is that CEGUI DOESN'T activate a window that gets shown. you have to manually activate a window when you create it (and want it to be active, of course).

== Extending the effect ==
* You could also automatically activate a window as soon as it's shown. for this you could subscribe to the "a window gets shown" global event and then just call ea.window->activate( );
Edit: Hmm I tried this one but wasn't able to get it to work. If someone has success, please tell us how you did it in the forums.

* You could try to make the window's transparency degree dependent on it's position in the stack. That means the most recent windows get less transparent while the "oldest" windows get very transparent. To do this, just loop trough the stack - that would be a list - and set every window's transparency accordingly. Do this when a window gets active AND when a window gets closed. You would also need to never have the same window twice in the stack, as it would screw your results up.

--[[User:Pompei2|Pompei2]] 06:00, 6 May 2007 (PDT)

----
----
you can add more cool effects here.

News Archive

2007-05-04T19:52:45Z

Pompei2: /* Site Moved (again) */

=== Release of 0.5.0b source packages by [[User:CrazyEddie|CrazyEddie]] 28th November 2006 ===
We have issued new versions of the 0.5.0 source packages - the previous ones were missing the files for the Microsoft Direct3D based renderer modules, the packages contain no other changes Thanks go to dmail for raising this issue.

=== Release of 0.5.0b binary packages for Win32 by [[User:CrazyEddie|CrazyEddie]] 14th November 2006 ===
The Win32 binary dependency and SDK packages released on the 6th contained an inconsistency related to the SILLY library. Today I have issued a new set of binary packages which have been fixed - the new version is known as 0.5.0b, and contains no other changes. Many thanks to forum member vasmann for alerting me to the issue.

=== Release of 0.5.0 stable by [[User:CrazyEddie|CrazyEddie]] 6th November 2006 ===
It has been almost a year in the making, but it is finally here! The CEGUI development team is immensely proud to announce the release of Crazy Eddie's GUI System 0.5.0 - the first stable release of code in the 0.5.x series.

There are pretty vast changes in this release from the previous stable (0.4.1) - many of these changes are breaking, so please agian review [[Release Notes 0.5.X]] to see details of most of these changes.

This release consists of various files that you may need, depending on your usage of the system. We are providing source packages, documentation packages, dependency packages, and binary SDK packages (for VC7.1 and VC8).

To coincide with this release, we are also happy to announce a stable 0.1.0 release of Simple Image Loading LibrarY (SILLY), and the 0.5.0 release of the CELayoutEditor. Please see the [[Downloads|downloads page]] for full details.

=== CEGUI 0.5.0 Release Candidate 2 by [[User:Dalfy|Dalfy]] 13 august 2006 ===
We are pleased to announce the second release candidate of the 0.5 branches of CEGUI. There has been a lot of changes between 0.4.1 and 0.5.0. They are listed in [[Release Notes 0.5.X]]. Please have a try at it and help us get a final release soon. Check the download page.

=== CEGUI 0.5.0 Release Candidate 1 by [[User:Dalfy|Dalfy]] 20 June 2006===
We are pleased to announce the first release candidate of the 0.5 branches of CEGUI. There has been a lot of changes between 0.4.1 and 0.5.0. They are listed in [[Release Notes 0.5.X]]. Please have a try at it and help us get a final release soon by sending a lot of bug report in Mantis bug tracker. The download page for CEGUI-0.5.0-RC1 contains some typos but most link are already valid and mirrored on sourceforge. The link on the download page are going to be fixed during the day.

For any question regarding this release you can use either the forum either irc.

=== Migration to Subversion by [[User:CrazyEddie|CrazyEddie]] 11:13, 3 April 2006 (PDT) ===
We have taken the decision to migrate the code for main CEGUI Mk-2 library and the CELayoutEditor tool from using the CVS revision control system, over to Subversion (SVN). If you're using the stable releases, this will not affect you at all. If you're using code out of some branch of CVS, then you will need to switch to SVN instead - we will not be maintaining both repositories. You will find that for general usage, CVS and SVN are similar, and have similar commands. For Windows users, we heartily recommend the use of [http://tortoisesvn.tigris.org/ TortoiseSVN].

For full details of how to obtain the source code from the subversion repository, please see the page [[HOWTO: Obtain the library source from subversion]]

All 'ceguiaddons' projects will continue to use CVS for revision control.

=== Site Moved (again) ===
We have now moved the site back to the sourceforge servers, and made a few changes as to the way the site is handled in general - as you have probably noticed!

Basically the main 'content' areas of the site are now entirely wiki based, and we also have a few other bits installed to handle certain requirements where the wiki is less suited to the task.

The features of the new site are:
* Wiki based system for all main site content
* phpBB2 being used for community forums
* Coppermine based gallery
* Mantis for all bug and feature tracking
* Single, unified, log-in for all site areas

News Archive

2007-05-04T19:52:34Z

Pompei2:

Tutorials

2007-05-04T19:47:56Z

Pompei2: spaced all parts with the same amount.

=== CrazyEddie's Beginner Guides ===
* [[The Beginner Guide to Getting CEGUI Rendering]] - How to initialise CEGUI to render properly.
* [[The Beginner Guide to Loading Data Files and Initialisation]] - How to load some data files and perform basic system initialisation.
* [[The Beginner Guide to Creating a CEGUI Window]] - How to create a simple window and get it on screen.
* [[The Beginner Guide to Injecting Inputs]] - How to inject inputs into CEGUI and get interactive.

=== Scripting with CEGUI ===
* [[Getting Started with Lua and CEGUI]] - How to initialise CEGUI with a Lua script module and configuration file.
* [[Handling Events from Lua]] - How to load Lua script files and bind CEGUI events to Lua functions.
* [[Writing CEGUI scripts]] - Code snippets
* [[Adding LuaScriptModule to Sample_FirstWindow]] - Experience adding scripting to an existing sample.
* [http://www.gpwiki.org/index.php/Crazy_Eddies_GUI_System:Tutorials:Creating_a_scriptable_interface_using_CEGUI Creating a scriptable interface using CEGUI]

=== Window System Examples ===
* [[Using CEGUI with SDL and OpenGL]] - Guidelines on how to get SDL, OpenGL and CEGUI running together.
* [[Using CEGUI with Producer and OpenGL]] - Guidelines on how to render and inject input to CEGUI from the Producer API.
* [http://artis.imag.fr/Membres/Xavier.Decoret/resources/CEGUI/ Using CEGUI with Qt/QGLViewer]
* [[Using CEGUI with GLUT]] - Some tips on using OpenGL's GLUT with CEGUI.

=== Extending CEGUI ===

* [[Using Expat XML parser within CEGUI]] - How to add support for another XML parser.

=== Skins - Tutorial For Artists ===
* [[Creating Skins]] - Extra notes for artists on how to create skins.
* [[The Beginners Guide to Falagard skinning - Part I]] - Learn by doing a Button.
* [[The Beginners Guide to Falagard skinning - Part II]] - More Falagard fun, this time with the Editbox.

=== Overviews ===
* [[Overview of GUI files]] - A quick introduction to all the XML files used by CEGUI.
* [[Overview of resource system enhancements in 0.5.0]] - Introduction to enhancements made for the 0.5.0 release.

=== Miscellaneous HOW-TOs ===
* [[Create ImageButtons]] - A few different ways to create image buttons.
* [[Create a CheckListboxItem]] - Create a CheckListBoxItem that you can use with ItemListbox.
* [[Identifying Multiple Event Sources From A Single Callback]]
* [[Cool window effects]] - A collection of cool "special" effects on (frame)windows.

Tutorials

2007-05-04T19:45:44Z

Pompei2:

FAQ

2007-05-03T21:57:10Z

Pompei2: /* What properties are available for use in XML layouts, and what format do I use for the value strings? */

== General Questions ==
=== What is CEGUI? ===
CEGUI stands for ''Crazy Eddie's Gui System''; a free library providing windowing and widgets for graphics APIs / engines where such functionality is not natively available, or severely lacking. The library is object orientated, written in C++, and targeted at games developers who should be spending their time creating great games, not building GUI sub-systems!

CEGUI is used as the GUI of choice in the [http://www.ogre3d.org Ogre3D project] but supports Microsoft® DirectX® 8.1 and 9, OpenGL, and the Irrlicht engine natively.

CEGUI was started by Paul Turner ("[[User:CrazyEddie|CrazyEddie]]") about two years ago and is currently in it's second major revision, "Mk2". The project supports windows, linux and MacOS.

=== How is CEGUI licensed? ===
Up and until version 0.4.1, CEGUI '''is''' licenced under [http://www.gnu.org/licenses/lgpl.html LGPL], which basically means you can dynamically link to it (ie. use it as a library) in a non-GPL project, as long as you fulfil the other requirements of the LGPL.

However, as from 0.5, the library will be released under the [http://www.opensource.org/licenses/mit-license.php MIT] licence, which is less restrictive then LGPL. You may for example statically link to libraries. The main reason for this switch is the fact that the Ogre3D project has started to provide dual licensing to allow console development. And in order to keep CEGUI as their preferred GUI system, we have switched as well.

=== What is the situation with the Falagard components and the Creative Commons license? ===
There is no situation! The Creative Commons license only applies to the documentation where that notice appears; the source code, libraries, and all other materials relating to the Falagard skinning system are licensed under LGPL or MIT (depending upon the version; see above).

=== Why is the Falagard documentation licensed seperately? Why is it not LGPL/MIT like the rest of the library? ===
Originally that documentation was only to be available as a PDF file intended for self-printing into a mini-book, and the "this work" portion of the license notification applies to the text of that book; the documentation is considered a seperate work from the code / library itself, and so it licensed seperately.

=== How much does CEGUI cost? ===
Nothing. The use of CEGUI is totally free within the bounds of the license as described above.

=== I am developing a commercial, closed-source product. Should i use the 0.4 or 0.5 version of the library? ===
When you are creating a product for PC, where it is possible for users to update any of your used third-party DLL's (a requirement for LGPL), you can choose both versions. However if you are shipping a product on a read-only device, such as a console DVD, you must use 0.5 or higher, because the MIT license does not require that users can update anything.

However before deciding, do always carefully check the mentioned licenses to make sure that your project doesn't do something uncommon.

=== I am not happy with the LGPL / MIT license, do you offer alternative licensing? ===
No. Alternative licensing is not available, nor is it planned. But you won't find anything much less restrictive then the MIT license.

=== Does CEGUI rely upon any third party libraries? If so what are they? ===
CEGUI currently depends upon the following external libraries:
{| width="100%"
|| '''Library''' || '''Required''' || '''Url''' || '''License'''
|-
|| FreeType2 || yes || [http://www.freetype.org/freetype2/index.html http://www.freetype.org/freetype2/index.html] || BSD-like [http://www.freetype.org/FTL.TXT FreeType License] ou [http://www.freetype.org/GPL.TXT GPL]
|-
|| Perl C Regular Expression || yes || [http://www.pcre.org/ http://www.pcre.org/] || [http://www.pcre.org/license.txt BSD]
|-
|| Xerces-C++ || no || [http://xerces.apache.org/ http://xerces.apache.org/] || [http://www.apache.org/licenses/LICENSE-2.0.html Apache Software License, Version 2.0]
|-
|| Expat || no || [http://expat.sourceforge.net/ http://expat.sourceforge.net/] || [http://www.opensource.org/licenses/mit-license.html MIT]
|-
|| Libxml || no || [http://www.xmlsoft.org/ http://www.xmlsoft.org/] || [http://www.opensource.org/licenses/mit-license.html MIT]
|-
|| DevIL || no || [http://openil.sourceforge.net/ http://openil.sourceforge.net/] || [http://openil.sourceforge.net/license.php LGPL License Version 2.1]
|}
You will also require a supported rendering system, and some form of input library.

=== Do I have to compile the third part libraries myself? ===
It depends. Under Linux and similar systems, you will need to perform your own compilation. For Microsoft® Windows® users, we have supplied packages containing binary versions of the libraries for a selection of popular compiler configurations. See the "Current Releases" on the home page.

=== You mentioned something about "supported rendering systems", what's that all about and which systems are supported? ===
CEGUI can be used with various rendering systems. There are currently CEGUI renderer modules for Microsoft® DirectX® 8.1 and 9, OpenGL, the Ogre engine, and the Irrlicht engine.

=== There is no renderer module for my rendering engine or API of choice, will other rendering system be supported? ===
It is likely that, over time, CEGUI will add support for other APIs and engines. Having said this, it is fairly simple to write your own renderer module for CEGUI, so you might consider taking that option if you do not want to wait.

=== And what about input libraries? ===
CEGUI requires you to ''inject'' inputs into it, these inputs can come from any source that you choose. All you need to do is pass mouse movements, mouse button up and down events, and keyboard inputs to CEGUI.

=== Why doesn't CEGUI collect its own inputs? Why do I need to inject the inputs myself? ===
CEGUI does not collect its own input so that the system can remain as flexible as possible. We didn't want to tie people down to one system or input library.

=== I have seen mention of a Lua scripting module, how can I get this? ===
The Lua scripting module is provided with CEGUI and resides in the same source repository. Downloading CEGUI binary/source/svn will get you everything you need.

=== I can't find many of the things you talk about in my crayzedsgui code, what's wrong? ===
You probably have one of the older Mk-1 alpha releases. Get the newer Mk-2 releases instead, the archive files for these generally have names with cegui_mk2 in them.

=== Why are there two versions of the system? ===
The Mk-1 version was a Windows®/DirectX® only library and was really a dry run for what became the Mk-2 system. There was only ever 'alpha' versions of the Mk-1 code, so it was never anywhere near finished.

=== Are the Mk-1 and Mk-2 systems interface compatible? ===
No. The interfaces of the two systems are totally different, although many of the general concepts have remained the same.

=== The Mk-1 system is so much more lightweight than the Mk-2 system. Can I still use the Mk-1 code? Is the Mk-1 code still being developed and supported? ===
Short Answer: Not really.

Long Answer: There were too many weak areas within the Mk-1 system and development on this version has ceased completely. There is no longer any support for the Mk-1 version; in general it would be better for everyone if they migrated to the Mk-2 version of the system.

=== I am having major troubles integrating CEGUI with my project, will you do it for me? ===
No. The CEGUI developers have enough to do without writing users projects for them. Follow the Howto's and Tutorials from the home page.

=== I have (or think I have) found a bug. How should I proceed? ===
If you are certain that it's a bug and not, for example, a misunderstanding of what is happening, then the bug should be reported via the [http://www.cegui.org.uk/mantis/index.php | Mantis Tracker] However, before submitting a bug to the tracker, it is asked that you first do a quick search to see if the bug has already been reported. If you are unsure whether something is a bug or not, then it may be discussed on the web site forums prior to submitting a bug report to the project bug tracker.

=== I notice that feature/widget 'X' is missing. Will this be added to CEGUI? ===
Requests for new features and/or widgets are welcomed in this forum: http://www.cegui.org.uk/phpBB2/viewforum.php?f=3&sid=587eedf3463c00490686f8cddc61a257
This is the best way because most people will read it, including the team. This helps others to give input as well, which migth result in clearly defined requests.

Note that no promises are made with regards to which features will and will not be added, or how long such things will take, but all requests will be seriously considered.

=== How can I get involved with CEGUI development? ===
Each new member gets added by invitation by the current team. Most probably because that person has contributed some valuable patches, or is of great help in the forums. It will of course depend on the current state of the project to know which positions are required.

So the best way to become involved is to show your face at the web site forums, the irc channel, and state what your intentions are (to help in avoiding duplicated effort), thereby becoming a constructive individual for CEGUI and its community. And some patches are a huge pro!

=== Is there managed code / Microsoft .Net support for the CEGUI library? ===
Yes, there is ''ceguisharp'' at http://ceguisharp.sourceforge.net/ This is a C# port of the library which will support Managed Direct 3D, OpenGL, as well as higher-level engines such as the excellent Axiom rendering engine.

=== This FAQ doesn't answer my question, what should I do now? ===
Feel free to post your question on the web site forums, somebody will gladly answer your question and/or offer further advice.

== Building CEGUI ==

This section has moved to [http://www.cegui.org.uk/wiki/index.php/HOWTO:_Obtain_the_library_source_from_subversion New location]

== Usage Questions ==
''(This whole section should be moved to a Tutorial or a Howto).''
=== What is the correct way to subscribe for an event? ===
Event notification is a vital aspect of GUI programming. CEGUI handles those using subscribers.
In order to subscribe a window for an event, you have to call the method 'Window::subscribeEvent', passing the function
to be called when the specified event occurs, and the instance on which the method is called.

class MyButtonHandler
{
private:
PushButton* mButton;

public:
MyButtonHandler::MyButtonHandler(PushButton* btn) : mButton(btn)
{
btn->subscribeEvent(PushButton::EventClicked, Event::Subscriber(&MyButtonHandler::ButtonClicked,this));
}

bool MyButtonHandler::ButtonClicked(const EventArgs&)
{
//This function gets called when the button is clicked
std::cout << "Button clicked" << std::endl;
}

The 'subscribeEvent' method returns an Event::Connection, which can be used later to unsubscribe for a registered event with
the 'disconnect' method.

Event::Connection myCon = btn->subscribeEvent(...);

...

myCon->disconnect();

In order to totally remove the event itself, you have to call the 'removeEvent' function:
all the connections to the specified event will be disconnected.
There's also an Event::ScopedConnection, which can be used to auto-unsubscribe when the event goes out of scope.

Similar way for the scripted events, which can be subscribed with the 'subscribeScriptedEvent' method.
In addition, you can do it in XML, using this syntax:

<Event Name="Clicked" Function="luabtn_clicked" />

=== How can I make the ListBox highlight the selected item? ===
In order to highlight selected items you need to set selection brush image and the selection colours of that item. The selection image is modulated by the colours you set. Note, that the alpha component needs to be smaller than 1.0, for the content of the selected item to be seen.
// set selection highlight to a half transparent blue to red gradient.
colour blue(0.0, 0.0, 1.0, 0.5);
colour red(1.0, 0.0, 0.0, 0.5);
myListBoxItem->setSelectionColours(blue, blue, red, red);
// this default image is a simple white rectangle
myListBoxItem->setSelectionBrushImage("TaharezLook", "ListboxSelectionBrush");

=== How can I remove the border of a StaticImage? ===
Either put the following property into the window definition:
<Property Name="FrameEnabled" Value="false" />
Or set it by code:
myStaticImage->setFrameEnabled(false);

=== How can I set the background of a StaticImage? ===
The first thing you need in order to do this is an Imageset that defines the Image that you wish to use. When wanting to use an image file for this as you suggest, you basically have an imageset defined like this:
<?xml version="1.0" ?>
<Imageset Name="BackdropImageset" Imagefile="backdrop.tga" NativeHorzRes="1024" NativeVertRes="768" AutoScaled="true">
<Image Name="Backdrop" XPos="0" YPos="0" Width="1024" Height="768" />
</Imageset>

What this does is define an Imageset using the backdrop.tga. A single image "Backdrop" is defined that starts at location (0,0) and is 1024 x 768 in size. You should be careful in that the source image file should have dimensions that are powers of two - this is because the image is loaded as a texture, and may be stretched if the powers-of-two requirement is not observed.<br>
Once you have your imageset defined, you can load it either by adding a reference to it in whichever scheme you are loading, or manually using the ImagesetManager:
CEGUI::ImagesetManager::getSingleton().createImageset("myImageset.imagset");
Once the thing is loaded, you set the image into the StaticImage like so:
myStaticImage->setImage("BackdropImageset", "Backdrop");
Notice that the names we specify here are the ones that were originally specified in the imageset XML file.<br>

=== I can't see the items I've added to my Combobox, how do I get the list to show when I press the button? ===
The height you specify for the combobox widget includes the height of the drop down list; it's not just for the 'Editbox' portion of the widget (the height of which is usually automatically determined based upon the font). Ensure that when specifying the height for your combobox, you have provided sufficient space for the list to appear.

=== What properties are available for use in XML layouts, and what format do I use for the value strings? ===
If you start at the documentation for the base Property class ([http://www.cegui.org.uk/api_reference/classCEGUI_1_1Property.html Property base]), you will get an inheritance diagram showing all properties in the system. When you click one, you'll get its page. Each page has a description of the format in which you should provide its value.

Besides, as an overview, each widget has its properties placed within an appropriately named C++ namespace within the [http://www.cegui.org.uk/api_reference/namespaces.html namespaces section of the API reference].

Also, remember that properties are inherited. So for example, when looking up properties for a PushButton, also check the properties for ButtonBase and Window too - since these properties are also available to you.

An [http://www.cegui.org.uk/wiki/index.php/SetProperty overview of all properties of every widget], with a short description of each property has been automatically generated by [http://www.cegui.org.uk/wiki/index.php?title=PropertyFinder Rackle's PropertFinder]

The Beginners Guide to Falagard skinning - Part II

2007-03-30T20:10:44Z

Pompei2:

== Introduction ==
Last time we looked at the essential basics to get something running with Falagard. This is great, but a simplistic look'n'feel for a button is a bit boring. So lets step forward and learn something new.

In this tutorial we will create a look'n'feel for the ''Editbox'' window type. This widget is interactive and uses new parts of the Falagard system, making it an excellent target for another tutorial.

So let's get started...

== Requirements ==
We'll start out by looking at the requirements for the ''Editbox'' window type. Like always, the information we're looking for can be found in the [[Falagard System base widgets reference]].

In there we'll see that the ''Editbox'' is a bit more complex than the ''Button''. But fear not - we'll get through every part of it ;-)

Let's start out with the ''StateImagery'' needed for this widget:
* Enabled
* Disabled
* ReadOnly
* ActiveSelection
* InactiveSelection

Unlike the ''Button'' we don't have any optional states. ''Enabled'' and ''Disabled'' should speak for themselves. ''ReadOnly'' is used when the ''Editbox'' is in read-only mode (easy huh?).

The ''ActiveSelection'' state is somewhat special. It should define what imagery to render for the selection graphics itself when the window is in an activated state (has focus).
''InactiveSelection'' is the same, except it is used when the window is '''not''' active (does'nt have focus).

Besides the ''StateImagery'' needed, a ''Editbox'' also requires a ''NamedArea'' called '''TextArea''' and a ''ImagerySection'' named '''Carat''' (yes, car'''a'''t).
We'll have a much closer look at these later on.

The initial XML (with the parts we know about) looks like this:

<?xml version="1.0" ?>
<Falagard>
<ImagerySection name="Carat">
</ImagerySection>
<StateImagery name="Enabled">
</StateImagery>
<StateImagery name="Disabled">
</StateImagery>
<StateImagery name="ReadOnly">
</StateImagery>
<StateImagery name="ActiveSelection">
</StateImagery>
<StateImagery name="InactiveSelection">
</StateImagery>
</Falagard>

We'll fill it out as we go...

== Imagery ==
This look'n'feel will use a frame consisting of 8 different images from our favorite imageset ''MyImages''. Furthermore we'll have a single image stretched to fill the hole in this frame. The images will have names that are easy to interpret:
{| cellpadding="15" border="1"
|+ Frame setup
| TL || align="center" | T || TR
|-
| align="center" | L || Bg|| align="center" |R
|-
| BL || align="center" | B || BR
|}

Each prefixed with '''Editbox'''. Forming imagenames like '''EditboxTL''' etc.

The ''FrameComponent'' tag may only occur inside an ''ImagerySection''. Just like the ''ImageryComponent'' and ''TextComponent'' that we used in part I.

Using the ''FrameComponent'' is very much like using the ''ImageryComponent'' all the tags allowed are the same, but a ''FrameComponent'' allows up to nine images to be specified. It's purpose is to make making frames easy :-)
A ''FrameComponent'' is special in the way it handles formatting compared to ''ImageryComponent'' though. Any formatting options are only applied to the background image - if it's specified. Yes. We don't have to set all nine of them. We can just choose the image "positions" we need. In our case we'll use all of them tough...

Let's look at the XML for this ''FrameComponent'':

<FrameComponent>
<Area>
<Dim type="LeftEdge">
<AbsoluteDim value="0" />
</Dim>
<Dim type="TopEdge">
<AbsoluteDim value="0" />
</Dim>
<Dim type="RightEdge">
<UnifiedDim scale="1" offset="0" type="RightEdge" />
</Dim>
<Dim type="BottomEdge">
<UnifiedDim scale="1" offset="0" type="BottomEdge" />
</Dim>
</Area>
<Image type="TopLeftCorner" imageset="MyImages" image="EditboxTL" />
<Image type="TopEdge" imageset="MyImages" image="EditboxT" />
<Image type="TopRightCorner" imageset="MyImages" image="EditboxTR" />
<Image type="RightEdge" imageset="MyImages" image="EditboxR" />
<Image type="BottomRightCorner" imageset="MyImages" image="EditboxBR" />
<Image type="BottomEdge" imageset="MyImages" image="EditboxB" />
<Image type="BottomLeftCorner" imageset="MyImages" image="EditboxBL" />
<Image type="LeftEdge" imageset="MyImages" image="EditboxL" />
<Image type="Background" imageset="MyImages" image="EditboxBg" />
<VertFormat type="Stretched" />
<HorzFormat type="Stretched" />
</FrameComponent>

You should recognise the area. It's the full area of the window, exactly like the areas we used in part I.
Reason: We want the frame and background to cover the entire window. Simple :-)

Nine images are specifed. The order does not matter.
But note that compared to the ''ImageryComponent'' used last time, we must specify a type attribute for the images.
This is so Falagard knows where to place this image in the frame.
These are of course listed in the [[Falagard System XML Enumerations reference]].

The format both horizontally and vertically is ''Stretched''. This ensures that the background image is stretched to fill as much as possible of the "hole" created by the border images (TL,T,TR etc.).

We'll use this frame for all the 3 states (''Enabled'', ''Disabled'', ''ReadOnly''), but we want the colours to be a little different in each state. In part I we created a new property to hold the colour of the Text. To show a different approach, we'll "hard-code" the frame colours into this look'n'feel.

CEGUI supports using a colour rectangle to modulate the colours of anything it renders. This makes it possible to "apply" nice colour gradients to our frame imagery.

The ''Normal'' state will use the colours, unmodified from the image file.

The ''Disabled'' state will use gray to darken the frame imagery

In the ''ReadOnly'' state we'll create a gradient that is white in the top-left corner, and slightly grayish for the three other corners. When applied to the imagery this will result in the top-left corner using exactly the same colours as in the image file, and the three other corners being slightly darkened.

To use this frame component we must - like stated earlier - fit it in a ''ImagerySection''. We'll call this new imagery section "frame".

This is all the we need to write up the xml for this frame, and use it in our states, so now the XML looks like this:

<?xml version="1.0" ?>
<Falagard>
<b><ImagerySection name="frame">
<FrameComponent>
<Area>
<Dim type="LeftEdge">
<AbsoluteDim value="0" />
</Dim>
<Dim type="TopEdge">
<AbsoluteDim value="0" />
</Dim>
<Dim type="RightEdge">
<UnifiedDim scale="1" offset="0" type="RightEdge" />
</Dim>
<Dim type="BottomEdge">
<UnifiedDim scale="1" offset="0" type="BottomEdge" />
</Dim>
</Area>
<Image type="TopLeftCorner" imageset="MyImages" image="EditboxTL" />
<Image type="TopEdge" imageset="MyImages" image="EditboxT" />
<Image type="TopRightCorner" imageset="MyImages" image="EditboxTR" />
<Image type="RightEdge" imageset="MyImages" image="EditboxR" />
<Image type="BottomRightCorner" imageset="MyImages" image="EditboxBR" />
<Image type="BottomEdge" imageset="MyImages" image="EditboxB" />
<Image type="BottomLeftCorner" imageset="MyImages" image="EditboxBL" />
<Image type="LeftEdge" imageset="MyImages" image="EditboxL" />
<Image type="Background" imageset="MyImages" image="EditboxBg" />
<VertFormat type="Stretched" />
<HorzFormat type="Stretched" />
</FrameComponent>
</ImagerySection></b>
<ImagerySection name="Carat">
</ImagerySection>
<StateImagery name="Enabled">
<b><Layer>
<Section section="frame" />
</Layer></b>
</StateImagery>
<StateImagery name="Disabled">
<b><Layer>
<Section section="frame">
<Colours topLeft="FF7F7F7F" topRight="FF7F7F7F" bottomLeft="FF7F7F7F" bottomRight="FF7F7F7F" />
</Section>
</Layer></b>
</StateImagery>
<StateImagery name="ReadOnly">
<b><Layer>
<Section section="frame">
<Colours topLeft="FFFFFFFF" topRight="FFDFDFDF" bottomLeft="FFDFDFDF" bottomRight="FFDFDFDF" />
</Section>
</Layer></b>
</StateImagery>
<StateImagery name="ActiveSelection">
</StateImagery>
<StateImagery name="InactiveSelection">
</StateImagery>
</Falagard>

The frame component has been added, and the ''Enabled'', ''Disabled'' and ''ReadOnly'' states have been set up to use them. The only new thing is really the ''Colours'' tag inside the ''Section'' tags for "frame".

It behaves just like the ''ColourProperty'' tag we used in part I, except you can specify a colour to use for each corner.
It's attributes
* topLeft
* topRight
* bottomLeft
* bottomRight
Each specify a single colour of the same format we used for ''ColourProperty'' (AARRGGBB in hex).

== Text ==
Remeber something about a ''NamedArea''? Either way we're going to look at it now. The ''Editbox'' widget requires us to define a named area so it knows where to render, the text we type in, the caret (the marker that shows us where the characters we type will be inserted) and our selection.

In this look'n'feel, we want the text to be rendered inside our frame. That is we dont want the text to cover the frame imagery itself, only the background of it. Falagard provides a ''ImageDim'' tag that we can use to extract the width and height from the images we used for the frame. Falagard also provides a ''DimOperator'' tag that we can use to do a little math on our dimensions. These features will be the core of our ''NamedArea'' which will be named '''TextArea''' (Stated in the requirements... Remember?)

The only thing we must (and may) specify in a ''NamedArea'' is a ''Area''.

If we take a look back at the ''Area'' tag, we know that it must specify four dimensions. ''LeftEdge'', ''TopEdge'', ''RightEdge'' and ''BottomEdge''. You might remember that we can specify ''Width'' instead of ''RightEdge'', and ''Height'' instead of ''BottomEdge''. But we're not going to do that. Just so you know (and don't forget) ;-)

We start out with a "empty" XML and fill it out as we go. For now it looks like this:

<NamedArea name="TextArea">
<Area>
<Dim type="LeftEdge">
</Dim>
<Dim type="TopEdge">
</Dim>
<Dim type="RightEdge">
</Dim>
<Dim type="BottomEdge">
</Dim>
</Area>
</NamedArea>

We start out with the left edge. In the frame we used the image named '''EditboxL''' for the left edge. And as the area we want to define is to lie inside the frame, we'll use the width of this specific image as the left edge of our area.
The XML for this ''ImageDim'' is like so:

<ImageDim imageset="MyImages" image="EditboxL" dimension="Width" />

The top edge is very similar except we'll use the height of the image named '''EditboxT''' instead.

<ImageDim imageset="MyImages" image="EditboxT" dimension="Height" />

The right edge is a bit more tricky. To start out we'll use a ''UnifiedDim'' that gives us the right edge of our widget.

<UnifiedDim scale="1" offset="0" type="RightEdge">
</Unified>

We use a seperate tag to close it, as by itself this ''UnifiedDim'' is not good enough. We still need the take the frame into accout. The image dimension we're after is the width of the image '''EditboxR'''. We must subtract this width from the right edge to ensure that the frame imagery is not overwritten by a long text string in the ''Editbox''.

The ''DimOperator'' can do this for us with XML like this:

<UnifiedDim scale="1" offset="0" type="RightEdge">
<b><DimOperator op="Subtract">
<ImageDim imageset="MyImages" image="EditboxR" dimension="Width" />
</DimOperator></b>
</Unified>

The ''DimOperator'' tag requires us to specify the attribute ''op'' with the name of the operation we want to perform as the value. The operations supported by Falagard are:
* Add
* Subtract
* Multiply
* Divide
We used ''Subtract'' to "move back" a little from our right edge to make sure we leave the frame imagery for the right edge alone.

The bottom edge of the area is very similar to the right. There are two differences. First we want the ''UnifiedDim'' to take the bottom edge of our window and not the right edge. Second we want to subtract the height of the image named '''EditboxB''' instead too.

This gives us this XML:

<UnifiedDim scale="1" offset="0" type="BottomEdge">
<DimOperator op="Subtract">
<ImageDim imageset="MyImages" image="EditboxB" dimension="Height" />
</DimOperator>
</Unified>

If we put these four dimensions into our ''NamedArea'' it looks like this:

<NamedArea name="TextArea">
<Area>
<Dim type="LeftEdge">
<b><ImageDim imageset="MyImages" image="EditboxL" dimension="Width" /></b>
</Dim>
<Dim type="TopEdge">
<b><ImageDim imageset="MyImages" image="EditboxT" dimension="Height" /></b>
</Dim>
<Dim type="RightEdge">
<b><UnifiedDim scale="1" offset="0" type="RightEdge">
<DimOperator op="Subtract">
<ImageDim imageset="MyImages" image="EditboxR" dimension="Width" />
</DimOperator>
</Unified></b>
</Dim>
<Dim type="BottomEdge">
<b><UnifiedDim scale="1" offset="0" type="BottomEdge">
<DimOperator op="Subtract">
<ImageDim imageset="MyImages" image="EditboxB" dimension="Height" />
</DimOperator>
</Unified></b>
</Dim>
</Area>
</NamedArea>

This is the complete ''NamedArea'' for our ''Editbox'' look'n'feel. If we fit it inside our full look'n'feel it will look like the XML below. Notice that the ''NamedArea'' is specifed before the ''ImagerySection''. This is required by Falagard.

<?xml version="1.0" ?>
<Falagard>
<b><NamedArea name="TextArea">
<Area>
<Dim type="LeftEdge">
<ImageDim imageset="MyImages" image="EditboxL" dimension="Width" />
</Dim>
<Dim type="TopEdge">
<ImageDim imageset="MyImages" image="EditboxT" dimension="Height" />
</Dim>
<Dim type="RightEdge">
<UnifiedDim scale="1" offset="0" type="RightEdge">
<DimOperator op="Subtract">
<ImageDim imageset="MyImages" image="EditboxR" dimension="Width" />
</DimOperator>
</Unified>
</Dim>
<Dim type="BottomEdge">
<UnifiedDim scale="1" offset="0" type="BottomEdge">
<DimOperator op="Subtract">
<ImageDim imageset="MyImages" image="EditboxB" dimension="Height" />
</DimOperator>
</Unified>
</Dim>
</Area>
</NamedArea></b>
<ImagerySection name="frame">
...
... saving space ...
...
</ImagerySection>
<ImagerySection name="Carat">
</ImagerySection>
<StateImagery name="Enabled">
<Layer>
<Section section="frame" />
</Layer>
</StateImagery>
<StateImagery name="Disabled">
<Layer>
<Section section="frame">
<Colours topLeft="FF7F7F7F" topRight="FF7F7F7F" bottomLeft="FF7F7F7F" bottomRight="FF7F7F7F" />
</Section>
</Layer>
</StateImagery>
<StateImagery name="ReadOnly">
<Layer>
<Section section="frame">
<Colours topLeft="FFFFFFFF" topRight="FFDFDFDF" bottomLeft="FFDFDFDF" bottomRight="FFDFDFDF" />
</Section>
</Layer>
</StateImagery>
<StateImagery name="ActiveSelection">
</StateImagery>
<StateImagery name="InactiveSelection">
</StateImagery>
</Falagard>

We don't reference '''TextArea''' anywhere. Just specifying it is all that is required according to the [[Falagard System base widgets reference]].

== Caret ==
The ''Editbox'' has a caret. This is a marker that shows us where we are typing and allows us to tell if we are inserting in the middle of the text or at the end etc. The text is split around it by CEGUI so we don't draw over the text rendering the point we're editing unreadable. All this is currently handled internally and all you need to do is create a ''ImagerySection'' name '''Carat'''.

note by Pompei2: You're reading right, the ''ImagerySection'' is named '''Carat''' although the right word is a caret.

When CEGUI needs render the caret (and the text) it will fetch this ''ImagerySection'' and render it at the appropriate position in the text.
We do not need to make a ''TextComponent'' in a ''Editbox'' to get the text to render. Because of the pecularities of the caret (and selection which we will handle later) it's all done automatically, by using the ''NamedArea'' '''TextArea''' we just specified along with the real pixel area of the window, to confine rendering to right rectangle on the screen.

Enough details. We just want to render a single image named '''EditboxCaret''' stretched vertically inside the '''TextArea'''.

Creating the ''ImagerySection'' is very much like creating the background for the ''Button'' in part I, the only real difference being the ''Area'' used. We'll look at the XML for this area, it's all made up by stuff we've already seen.

<Area>
<Dim type="LeftEdge">
<AbsoluteDim value="0" />
</Dim>
<Dim type="TopEdge">
<AbsoluteDim value="0" />
</Dim>
<Dim type="Width">
<ImageDim imageset="MyImages" image="EditboxCaret" dimension="Width" />
</Dim>
<Dim type="BottomEdge">
<UnifiedDim scale="1" offset="0" type="BottomEdge" />
</Dim>
</Area>

The first and second (left/top edges) ''Dim''s have the familiar ''AbsoluteDim'' with a value of zero. Nothing new here.

The third ''Dim'' on the other hand is new. It's now specified as "Width" and not "RightEdge" like we have done so far. Inside we have a ''ImageDim'' for the width of the caret image we're using. If we had used the regular ''UnifiedDim'', the caret itself would have the width our textarea (because the caret resides in the text area) and would have been very ugly...

The fourth dimension is the familiar ''UnifiedDim'' we have used in all the earlier areas.

We know from part I how to make a ''ImagerySection'' with a ''ImageryComponent''. This is all we need to render this single-image caret. The XML for our look'n'feel is nearing completion.

<?xml version="1.0" ?>
<Falagard>
<NamedArea name="TextArea">
...
... saving space ...
...
</NamedArea>
<ImagerySection name="frame">
...
... saving space ...
...
</ImagerySection>
<ImagerySection name="Carat">
<b><ImageryComponent>
<Area>
<Dim type="LeftEdge">
<AbsoluteDim value="0" />
</Dim>
<Dim type="TopEdge">
<AbsoluteDim value="0" />
</Dim>
<Dim type="Width">
<ImageDim imageset="MyImages" image="EditboxCaret" dimension="Width" />
</Dim>
<Dim type="BottomEdge">
<UnifiedDim scale="1" offset="0" />
</Dim>
</Area>
<Image imageset="MyImages" image="EditboxCaret" />
<VertFormat type="Stretched" />
</ImageryComponent></b>
</ImagerySection>
<StateImagery name="Enabled">
<Layer>
<Section section="frame" />
</Layer>
</StateImagery>
<StateImagery name="Disabled">
<Layer>
<Section section="frame">
<Colours topLeft="FF7F7F7F" topRight="FF7F7F7F" bottomLeft="FF7F7F7F" bottomRight="FF7F7F7F" />
</Section>
</Layer>
</StateImagery>
<StateImagery name="ReadOnly">
<Layer>
<Section section="frame">
<Colours topLeft="FFFFFFFF" topRight="FFDFDFDF" bottomLeft="FFDFDFDF" bottomRight="FFDFDFDF" />
</Section>
</Layer>
</StateImagery>
<StateImagery name="ActiveSelection">
</StateImagery>
<StateImagery name="InactiveSelection">
</StateImagery>
</Falagard>

We only specify the vertical formatting for the new ''ImageryComponent'' because we are specifying the area to exactly match the width of the image, and thus any formatting would have no effect. ''LeftAligned'' (the default) is just fine.

Now we just need to do something in the ''ActiveSelection'' and ''InactiveSelection'' states...

== Selection ==
When the user has selected text in the ''Editbox'', either with the mouse or the keyboard, CEGUI render the selection using the two additional states '''ActiveSelection''' and '''InactiveSelection'''.

The the window is active (has focus) it will use the state '''ActiveSelection''', if if does not have focus (inactive) yet still has a selection '''InactiveSelection''' will be used.

For the selection in this look'n'feel, we'll use a single image stretched over the selection area. This image will contain plain white in the image file so we can apply any colour(s) we choose to the selection imagery.
Let's call it '''White'''.

For '''ActiveSelection''' we'll use a classic blue colour, for inactive the same, except we'll make it 50% transparent.
We can avoid a colour tag in the '''ActiveSelection''' state if we specify the colours to use directly in the ''ImageryComponent''. We'll do that to show how it works.

We'll create a new ''ImagerySection'' for this "selection brush" named '''selection'''. XML follows:

<ImagerySection name="selection">
<ImageryComponent>
<Area>
<Dim type="LeftEdge">
<AbsoluteDim value="0" />
</Dim>
<Dim type="TopEdge">
<AbsoluteDim value="0" />
</Dim>
<Dim type="RightEdge">
<UnifiedDim scale="1" offset="0" type="RightEdge" />
</Dim>
<Dim type="BottomEdge">
<UnifiedDim scale="1" offset="0" type="BottomEdge" />
</Dim>
</Area>
<Image imageset="MyImages" image="White" />
<Colours topLeft="FF26458A" topRight="FF26458A" bottomLeft="FF26458A" bottomRight="FF26458A" />
<VertFormat type="Stretched" />
<HorzFormat type="Stretched" />
</ImageryComponent>
</ImagerySection>

We use a default area that you should recognise by now. CEGUI will automatically use the right size for the selection.
The image we use is the one called '''White''' from our favorite imageset '''MyImages'''. Like always ;-)
A colour tag has been added as well to make our selection some kind of blue...
The vertical and horizontal formatting is ''Stretched'' which is generally what you would want to do in a situation like this.

We'll "call" this ''ImagerySection'' from the '''ActiveSelection''' and '''InactiveSelection''' states. In the '''InactiveSelection''' state we'll further modulate the colours used by passing a 50% transparent white. This will have the effect of using the same colour as in the active state, but make that colour 50% transparent. We could have just specified the full colour to use in each state and remove the ''Colours'' tag from the ''ImageryComponent'', but I wanted to show that multiple modulations are possible with Falagard.

The states are the last thing missing from the look'n'feel, so let's take a look at the final XML (yay :-P ).

<?xml version="1.0" ?>
<Falagard>
<NamedArea name="TextArea">
<Area>
<Dim type="LeftEdge">
<ImageDim imageset="MyImages" image="EditboxL" dimension="Width" />
</Dim>
<Dim type="TopEdge">
<ImageDim imageset="MyImages" image="EditboxT" dimension="Height" />
</Dim>
<Dim type="RightEdge">
<UnifiedDim scale="1" offset="0" type="RightEdge">
<DimOperator op="Subtract">
<ImageDim imageset="MyImages" image="EditboxR" dimension="Width" />
</DimOperator>
</Unified>
</Dim>
<Dim type="BottomEdge">
<UnifiedDim scale="1" offset="0" type="BottomEdge">
<DimOperator op="Subtract">
<ImageDim imageset="MyImages" image="EditboxB" dimension="Height" />
</DimOperator>
</Unified>
</Dim>
</Area>
</NamedArea>
<ImagerySection name="frame">
<FrameComponent>
<Area>
<Dim type="LeftEdge">
<AbsoluteDim value="0" />
</Dim>
<Dim type="TopEdge">
<AbsoluteDim value="0" />
</Dim>
<Dim type="RightEdge">
<UnifiedDim scale="1" offset="0" type="RightEdge" />
</Dim>
<Dim type="BottomEdge">
<UnifiedDim scale="1" offset="0" type="BottomEdge" />
</Dim>
</Area>
<Image type="TopLeftCorner" imageset="MyImages" image="EditboxTL" />
<Image type="TopEdge" imageset="MyImages" image="EditboxT" />
<Image type="TopRightCorner" imageset="MyImages" image="EditboxTR" />
<Image type="RightEdge" imageset="MyImages" image="EditboxR" />
<Image type="BottomRightCorner" imageset="MyImages" image="EditboxBR" />
<Image type="BottomEdge" imageset="MyImages" image="EditboxB" />
<Image type="BottomLeftCorner" imageset="MyImages" image="EditboxBL" />
<Image type="LeftEdge" imageset="MyImages" image="EditboxL" />
<Image type="Background" imageset="MyImages" image="EditboxBg" />
<VertFormat type="Stretched" />
<HorzFormat type="Stretched" />
</FrameComponent>
</ImagerySection>
<ImagerySection name="Carat">
<ImageryComponent>
<Area>
<Dim type="LeftEdge">
<AbsoluteDim value="0" />
</Dim>
<Dim type="TopEdge">
<AbsoluteDim value="0" />
</Dim>
<Dim type="Width">
<ImageDim imageset="MyImages" image="EditboxCaret" dimension="Width" />
</Dim>
<Dim type="BottomEdge">
<UnifiedDim scale="1" offset="0" />
</Dim>
</Area>
<Image imageset="MyImages" image="EditboxCaret" />
<VertFormat type="Stretched" />
</ImageryComponent>
</ImagerySection>
<b><ImagerySection name="selection">
<ImageryComponent>
<Area>
<Dim type="LeftEdge">
<AbsoluteDim value="0" />
</Dim>
<Dim type="TopEdge">
<AbsoluteDim value="0" />
</Dim>
<Dim type="RightEdge">
<UnifiedDim scale="1" offset="0" type="RightEdge" />
</Dim>
<Dim type="BottomEdge">
<UnifiedDim scale="1" offset="0" type="BottomEdge" />
</Dim>
</Area>
<Image imageset="MyImages" image="White" />
<Colours topLeft="FF26458A" topRight="FF26458A" bottomLeft="FF26458A" bottomRight="FF26458A" />
<VertFormat type="Stretched" />
<HorzFormat type="Stretched" />
</ImageryComponent>
</ImagerySection></b>
<StateImagery name="Enabled">
<Layer>
<Section section="frame" />
</Layer>
</StateImagery>
<StateImagery name="Disabled">
<Layer>
<Section section="frame">
<Colours topLeft="FF7F7F7F" topRight="FF7F7F7F" bottomLeft="FF7F7F7F" bottomRight="FF7F7F7F" />
</Section>
</Layer>
</StateImagery>
<StateImagery name="ReadOnly">
<Layer>
<Section section="frame">
<Colours topLeft="FFFFFFFF" topRight="FFDFDFDF" bottomLeft="FFDFDFDF" bottomRight="FFDFDFDF" />
</Section>
</Layer>
</StateImagery>
<StateImagery name="ActiveSelection">
<b><Layer>
<Section section="selection" />
</Layer></b>
</StateImagery>
<StateImagery name="InactiveSelection">
<b><Layer>
<Section section="selection">
<Colours topLeft="7FFFFFFF" topRight="7FFFFFFF" bottomLeft="7FFFFFFF" bottomRight="7FFFFFFF" />
</Section>
</Layer></b>
</StateImagery>
</Falagard>

That's it folks. The look'n'feel is done. Hopefully you're starting to play around with the XML and making the look'n'feel suit you (or your artist ;-) ).
Again, feel free to add comments in the discussion page.

Stay tuned for part III...

--[[User:lindquist|lindquist]] 00:41, 14 Dec 2005 (CET)

Talk:The Beginners Guide to Falagard skinning - Part II

2007-03-30T20:06:55Z

Pompei2: /* Carat, not Caret (yes, strange) */

== Unified Area of the caret ? ==

I'm writing this just while reading (this great article :)).

In the part about the caret, when specifying the area it should use, you say this:
The third Dim on the other hand is new. It's now specified as "Width" and not "RightEdge" like we have done so far.
Inside we have a ImageDim for the width of the caret image we're using. If we had used the regular UnifiedDim,
the caret itself would have the width of the window and would have been very ugly...
This sounds strange to my intuition, as my intuition tells me that using the UnifiedDim the caret would have the width of THE AREA and not the window. Is my intuition bad, or did you make a mistake ?

Edit: Ok, while creating my editbox, I checked this, and now it is not only an intuition anymore, but a truth :-p I corrected this in your article.

--[[User:Pompei2|Pompei2]] 13:10, 29 March 2007 (PDT)

== Very good ==

yes, very good article, again :)

And I stay tuned for part III :-p

--[[User:Pompei2|Pompei2]] 13:10, 29 March 2007 (PDT)

== Carat, not Caret (yes, strange) ==

one other thing I noticed is that although this thing is called a "Caret", in CEGUI the sections and so one have to be called "Carat", else you get an exception.

I changed this too in your article.

--[[User:Pompei2|Pompei2]] 13:06, 30 March 2007 (PDT)

Talk:The Beginners Guide to Falagard skinning - Part II

2007-03-30T20:06:42Z

Pompei2: Carat, not Caret (yes, strange)

The Beginners Guide to Falagard skinning - Part II

2007-03-30T20:04:05Z

Pompei2: /* Caret */

== Introduction ==
Last time we looked at the essential basics to get something running with Falagard. This is great, but a simplistic look'n'feel for a button is a bit boring. So lets step forward and learn something new.

In this tutorial we will create a look'n'feel for the ''Editbox'' window type. This widget is interactive and uses new parts of the Falagard system, making it an excellent target for another tutorial.

So let's get started...

== Requirements ==
We'll start out by looking at the requirements for the ''Editbox'' window type. Like always, the information we're looking for can be found in the [[Falagard System base widgets reference]].

In there we'll see that the ''Editbox'' is a bit more complex than the ''Button''. But fear not - we'll get through every part of it ;-)

Let's start out with the ''StateImagery'' needed for this widget:
* Enabled
* Disabled
* ReadOnly
* ActiveSelection
* InactiveSelection

Unlike the ''Button'' we don't have any optional states. ''Enabled'' and ''Disabled'' should speak for themselves. ''ReadOnly'' is used when the ''Editbox'' is in read-only mode (easy huh?).

The ''ActiveSelection'' state is somewhat special. It should define what imagery to render for the selection graphics itself when the window is in an activated state (has focus).
''InactiveSelection'' is the same, except it is used when the window is '''not''' active (does'nt have focus).

Besides the ''StateImagery'' needed, a ''Editbox'' also requires a ''NamedArea'' called '''TextArea''' and a ''ImagerySection'' named '''Caret'''.
We'll have a much closer look at these later on.

The initial XML (with the parts we know about) looks like this:

<?xml version="1.0" ?>
<Falagard>
<ImagerySection name="Caret">
</ImagerySection>
<StateImagery name="Enabled">
</StateImagery>
<StateImagery name="Disabled">
</StateImagery>
<StateImagery name="ReadOnly">
</StateImagery>
<StateImagery name="ActiveSelection">
</StateImagery>
<StateImagery name="InactiveSelection">
</StateImagery>
</Falagard>

We'll fill it out as we go...

== Imagery ==
This look'n'feel will use a frame consisting of 8 different images from our favorite imageset ''MyImages''. Furthermore we'll have a single image stretched to fill the hole in this frame. The images will have names that are easy to interpret:
{| cellpadding="15" border="1"
|+ Frame setup
| TL || align="center" | T || TR
|-
| align="center" | L || Bg|| align="center" |R
|-
| BL || align="center" | B || BR
|}

Each prefixed with '''Editbox'''. Forming imagenames like '''EditboxTL''' etc.

The ''FrameComponent'' tag may only occur inside an ''ImagerySection''. Just like the ''ImageryComponent'' and ''TextComponent'' that we used in part I.

Using the ''FrameComponent'' is very much like using the ''ImageryComponent'' all the tags allowed are the same, but a ''FrameComponent'' allows up to nine images to be specified. It's purpose is to make making frames easy :-)
A ''FrameComponent'' is special in the way it handles formatting compared to ''ImageryComponent'' though. Any formatting options are only applied to the background image - if it's specified. Yes. We don't have to set all nine of them. We can just choose the image "positions" we need. In our case we'll use all of them tough...

Let's look at the XML for this ''FrameComponent'':

<FrameComponent>
<Area>
<Dim type="LeftEdge">
<AbsoluteDim value="0" />
</Dim>
<Dim type="TopEdge">
<AbsoluteDim value="0" />
</Dim>
<Dim type="RightEdge">
<UnifiedDim scale="1" offset="0" type="RightEdge" />
</Dim>
<Dim type="BottomEdge">
<UnifiedDim scale="1" offset="0" type="BottomEdge" />
</Dim>
</Area>
<Image type="TopLeftCorner" imageset="MyImages" image="EditboxTL" />
<Image type="TopEdge" imageset="MyImages" image="EditboxT" />
<Image type="TopRightCorner" imageset="MyImages" image="EditboxTR" />
<Image type="RightEdge" imageset="MyImages" image="EditboxR" />
<Image type="BottomRightCorner" imageset="MyImages" image="EditboxBR" />
<Image type="BottomEdge" imageset="MyImages" image="EditboxB" />
<Image type="BottomLeftCorner" imageset="MyImages" image="EditboxBL" />
<Image type="LeftEdge" imageset="MyImages" image="EditboxL" />
<Image type="Background" imageset="MyImages" image="EditboxBg" />
<VertFormat type="Stretched" />
<HorzFormat type="Stretched" />
</FrameComponent>

You should recognise the area. It's the full area of the window, exactly like the areas we used in part I.
Reason: We want the frame and background to cover the entire window. Simple :-)

Nine images are specifed. The order does not matter.
But note that compared to the ''ImageryComponent'' used last time, we must specify a type attribute for the images.
This is so Falagard knows where to place this image in the frame.
These are of course listed in the [[Falagard System XML Enumerations reference]].

The format both horizontally and vertically is ''Stretched''. This ensures that the background image is stretched to fill as much as possible of the "hole" created by the border images (TL,T,TR etc.).

We'll use this frame for all the 3 states (''Enabled'', ''Disabled'', ''ReadOnly''), but we want the colours to be a little different in each state. In part I we created a new property to hold the colour of the Text. To show a different approach, we'll "hard-code" the frame colours into this look'n'feel.

CEGUI supports using a colour rectangle to modulate the colours of anything it renders. This makes it possible to "apply" nice colour gradients to our frame imagery.

The ''Normal'' state will use the colours, unmodified from the image file.

The ''Disabled'' state will use gray to darken the frame imagery

In the ''ReadOnly'' state we'll create a gradient that is white in the top-left corner, and slightly grayish for the three other corners. When applied to the imagery this will result in the top-left corner using exactly the same colours as in the image file, and the three other corners being slightly darkened.

To use this frame component we must - like stated earlier - fit it in a ''ImagerySection''. We'll call this new imagery section "frame".

This is all the we need to write up the xml for this frame, and use it in our states, so now the XML looks like this:

<?xml version="1.0" ?>
<Falagard>
<b><ImagerySection name="frame">
<FrameComponent>
<Area>
<Dim type="LeftEdge">
<AbsoluteDim value="0" />
</Dim>
<Dim type="TopEdge">
<AbsoluteDim value="0" />
</Dim>
<Dim type="RightEdge">
<UnifiedDim scale="1" offset="0" type="RightEdge" />
</Dim>
<Dim type="BottomEdge">
<UnifiedDim scale="1" offset="0" type="BottomEdge" />
</Dim>
</Area>
<Image type="TopLeftCorner" imageset="MyImages" image="EditboxTL" />
<Image type="TopEdge" imageset="MyImages" image="EditboxT" />
<Image type="TopRightCorner" imageset="MyImages" image="EditboxTR" />
<Image type="RightEdge" imageset="MyImages" image="EditboxR" />
<Image type="BottomRightCorner" imageset="MyImages" image="EditboxBR" />
<Image type="BottomEdge" imageset="MyImages" image="EditboxB" />
<Image type="BottomLeftCorner" imageset="MyImages" image="EditboxBL" />
<Image type="LeftEdge" imageset="MyImages" image="EditboxL" />
<Image type="Background" imageset="MyImages" image="EditboxBg" />
<VertFormat type="Stretched" />
<HorzFormat type="Stretched" />
</FrameComponent>
</ImagerySection></b>
<ImagerySection name="Caret">
</ImagerySection>
<StateImagery name="Enabled">
<b><Layer>
<Section section="frame" />
</Layer></b>
</StateImagery>
<StateImagery name="Disabled">
<b><Layer>
<Section section="frame">
<Colours topLeft="FF7F7F7F" topRight="FF7F7F7F" bottomLeft="FF7F7F7F" bottomRight="FF7F7F7F" />
</Section>
</Layer></b>
</StateImagery>
<StateImagery name="ReadOnly">
<b><Layer>
<Section section="frame">
<Colours topLeft="FFFFFFFF" topRight="FFDFDFDF" bottomLeft="FFDFDFDF" bottomRight="FFDFDFDF" />
</Section>
</Layer></b>
</StateImagery>
<StateImagery name="ActiveSelection">
</StateImagery>
<StateImagery name="InactiveSelection">
</StateImagery>
</Falagard>

The frame component has been added, and the ''Enabled'', ''Disabled'' and ''ReadOnly'' states have been set up to use them. The only new thing is really the ''Colours'' tag inside the ''Section'' tags for "frame".

It behaves just like the ''ColourProperty'' tag we used in part I, except you can specify a colour to use for each corner.
It's attributes
* topLeft
* topRight
* bottomLeft
* bottomRight
Each specify a single colour of the same format we used for ''ColourProperty'' (AARRGGBB in hex).

== Text ==
Remeber something about a ''NamedArea''? Either way we're going to look at it now. The ''Editbox'' widget requires us to define a named area so it knows where to render, the text we type in, the caret (the marker that shows us where the characters we type will be inserted) and our selection.

In this look'n'feel, we want the text to be rendered inside our frame. That is we dont want the text to cover the frame imagery itself, only the background of it. Falagard provides a ''ImageDim'' tag that we can use to extract the width and height from the images we used for the frame. Falagard also provides a ''DimOperator'' tag that we can use to do a little math on our dimensions. These features will be the core of our ''NamedArea'' which will be named '''TextArea''' (Stated in the requirements... Remember?)

The only thing we must (and may) specify in a ''NamedArea'' is a ''Area''.

If we take a look back at the ''Area'' tag, we know that it must specify four dimensions. ''LeftEdge'', ''TopEdge'', ''RightEdge'' and ''BottomEdge''. You might remember that we can specify ''Width'' instead of ''RightEdge'', and ''Height'' instead of ''BottomEdge''. But we're not going to do that. Just so you know (and don't forget) ;-)

We start out with a "empty" XML and fill it out as we go. For now it looks like this:

<NamedArea name="TextArea">
<Area>
<Dim type="LeftEdge">
</Dim>
<Dim type="TopEdge">
</Dim>
<Dim type="RightEdge">
</Dim>
<Dim type="BottomEdge">
</Dim>
</Area>
</NamedArea>

We start out with the left edge. In the frame we used the image named '''EditboxL''' for the left edge. And as the area we want to define is to lie inside the frame, we'll use the width of this specific image as the left edge of our area.
The XML for this ''ImageDim'' is like so:

<ImageDim imageset="MyImages" image="EditboxL" dimension="Width" />

The top edge is very similar except we'll use the height of the image named '''EditboxT''' instead.

<ImageDim imageset="MyImages" image="EditboxT" dimension="Height" />

The right edge is a bit more tricky. To start out we'll use a ''UnifiedDim'' that gives us the right edge of our widget.

<UnifiedDim scale="1" offset="0" type="RightEdge">
</Unified>

We use a seperate tag to close it, as by itself this ''UnifiedDim'' is not good enough. We still need the take the frame into accout. The image dimension we're after is the width of the image '''EditboxR'''. We must subtract this width from the right edge to ensure that the frame imagery is not overwritten by a long text string in the ''Editbox''.

The ''DimOperator'' can do this for us with XML like this:

<UnifiedDim scale="1" offset="0" type="RightEdge">
<b><DimOperator op="Subtract">
<ImageDim imageset="MyImages" image="EditboxR" dimension="Width" />
</DimOperator></b>
</Unified>

The ''DimOperator'' tag requires us to specify the attribute ''op'' with the name of the operation we want to perform as the value. The operations supported by Falagard are:
* Add
* Subtract
* Multiply
* Divide
We used ''Subtract'' to "move back" a little from our right edge to make sure we leave the frame imagery for the right edge alone.

The bottom edge of the area is very similar to the right. There are two differences. First we want the ''UnifiedDim'' to take the bottom edge of our window and not the right edge. Second we want to subtract the height of the image named '''EditboxB''' instead too.

This gives us this XML:

<UnifiedDim scale="1" offset="0" type="BottomEdge">
<DimOperator op="Subtract">
<ImageDim imageset="MyImages" image="EditboxB" dimension="Height" />
</DimOperator>
</Unified>

If we put these four dimensions into our ''NamedArea'' it looks like this:

<NamedArea name="TextArea">
<Area>
<Dim type="LeftEdge">
<b><ImageDim imageset="MyImages" image="EditboxL" dimension="Width" /></b>
</Dim>
<Dim type="TopEdge">
<b><ImageDim imageset="MyImages" image="EditboxT" dimension="Height" /></b>
</Dim>
<Dim type="RightEdge">
<b><UnifiedDim scale="1" offset="0" type="RightEdge">
<DimOperator op="Subtract">
<ImageDim imageset="MyImages" image="EditboxR" dimension="Width" />
</DimOperator>
</Unified></b>
</Dim>
<Dim type="BottomEdge">
<b><UnifiedDim scale="1" offset="0" type="BottomEdge">
<DimOperator op="Subtract">
<ImageDim imageset="MyImages" image="EditboxB" dimension="Height" />
</DimOperator>
</Unified></b>
</Dim>
</Area>
</NamedArea>

This is the complete ''NamedArea'' for our ''Editbox'' look'n'feel. If we fit it inside our full look'n'feel it will look like the XML below. Notice that the ''NamedArea'' is specifed before the ''ImagerySection''. This is required by Falagard.

<?xml version="1.0" ?>
<Falagard>
<b><NamedArea name="TextArea">
<Area>
<Dim type="LeftEdge">
<ImageDim imageset="MyImages" image="EditboxL" dimension="Width" />
</Dim>
<Dim type="TopEdge">
<ImageDim imageset="MyImages" image="EditboxT" dimension="Height" />
</Dim>
<Dim type="RightEdge">
<UnifiedDim scale="1" offset="0" type="RightEdge">
<DimOperator op="Subtract">
<ImageDim imageset="MyImages" image="EditboxR" dimension="Width" />
</DimOperator>
</Unified>
</Dim>
<Dim type="BottomEdge">
<UnifiedDim scale="1" offset="0" type="BottomEdge">
<DimOperator op="Subtract">
<ImageDim imageset="MyImages" image="EditboxB" dimension="Height" />
</DimOperator>
</Unified>
</Dim>
</Area>
</NamedArea></b>
<ImagerySection name="frame">
...
... saving space ...
...
</ImagerySection>
<ImagerySection name="Caret">
</ImagerySection>
<StateImagery name="Enabled">
<Layer>
<Section section="frame" />
</Layer>
</StateImagery>
<StateImagery name="Disabled">
<Layer>
<Section section="frame">
<Colours topLeft="FF7F7F7F" topRight="FF7F7F7F" bottomLeft="FF7F7F7F" bottomRight="FF7F7F7F" />
</Section>
</Layer>
</StateImagery>
<StateImagery name="ReadOnly">
<Layer>
<Section section="frame">
<Colours topLeft="FFFFFFFF" topRight="FFDFDFDF" bottomLeft="FFDFDFDF" bottomRight="FFDFDFDF" />
</Section>
</Layer>
</StateImagery>
<StateImagery name="ActiveSelection">
</StateImagery>
<StateImagery name="InactiveSelection">
</StateImagery>
</Falagard>

We don't reference '''TextArea''' anywhere. Just specifying it is all that is required according to the [[Falagard System base widgets reference]].

== Caret ==
The ''Editbox'' has a caret. This is a marker that shows us where we are typing and allows us to tell if we are inserting in the middle of the text or at the end etc. The text is split around it by CEGUI so we don't draw over the text rendering the point we're editing unreadable. All this is currently handled internally and all you need to do is create a ''ImagerySection'' name '''Caret'''.

When CEGUI needs render the caret (and the text) it will fetch this ''ImagerySection'' and render it at the appropriate position in the text.
We do not need to make a ''TextComponent'' in a ''Editbox'' to get the text to render. Because of the pecularities of the caret (and selection which we will handle later) it's all done automatically, by using the ''NamedArea'' '''TextArea''' we just specified along with the real pixel area of the window, to confine rendering to right rectangle on the screen.

Enough details. We just want to render a single image named '''EditboxCaret''' stretched vertically inside the '''TextArea'''.

Creating the ''ImagerySection'' is very much like creating the background for the ''Button'' in part I, the only real difference being the ''Area'' used. We'll look at the XML for this area, it's all made up by stuff we've already seen.

<Area>
<Dim type="LeftEdge">
<AbsoluteDim value="0" />
</Dim>
<Dim type="TopEdge">
<AbsoluteDim value="0" />
</Dim>
<Dim type="Width">
<ImageDim imageset="MyImages" image="EditboxCaret" dimension="Width" />
</Dim>
<Dim type="BottomEdge">
<UnifiedDim scale="1" offset="0" type="BottomEdge" />
</Dim>
</Area>

The first and second (left/top edges) ''Dim''s have the familiar ''AbsoluteDim'' with a value of zero. Nothing new here.

The third ''Dim'' on the other hand is new. It's now specified as "Width" and not "RightEdge" like we have done so far. Inside we have a ''ImageDim'' for the width of the caret image we're using. If we had used the regular ''UnifiedDim'', the caret itself would have the width our textarea (because the caret resides in the text area) and would have been very ugly...

The fourth dimension is the familiar ''UnifiedDim'' we have used in all the earlier areas.

We know from part I how to make a ''ImagerySection'' with a ''ImageryComponent''. This is all we need to render this single-image caret. The XML for our look'n'feel is nearing completion.

<?xml version="1.0" ?>
<Falagard>
<NamedArea name="TextArea">
...
... saving space ...
...
</NamedArea>
<ImagerySection name="frame">
...
... saving space ...
...
</ImagerySection>
<ImagerySection name="Caret">
<b><ImageryComponent>
<Area>
<Dim type="LeftEdge">
<AbsoluteDim value="0" />
</Dim>
<Dim type="TopEdge">
<AbsoluteDim value="0" />
</Dim>
<Dim type="Width">
<ImageDim imageset="MyImages" image="EditboxCaret" dimension="Width" />
</Dim>
<Dim type="BottomEdge">
<UnifiedDim scale="1" offset="0" />
</Dim>
</Area>
<Image imageset="MyImages" image="EditboxCaret" />
<VertFormat type="Stretched" />
</ImageryComponent></b>
</ImagerySection>
<StateImagery name="Enabled">
<Layer>
<Section section="frame" />
</Layer>
</StateImagery>
<StateImagery name="Disabled">
<Layer>
<Section section="frame">
<Colours topLeft="FF7F7F7F" topRight="FF7F7F7F" bottomLeft="FF7F7F7F" bottomRight="FF7F7F7F" />
</Section>
</Layer>
</StateImagery>
<StateImagery name="ReadOnly">
<Layer>
<Section section="frame">
<Colours topLeft="FFFFFFFF" topRight="FFDFDFDF" bottomLeft="FFDFDFDF" bottomRight="FFDFDFDF" />
</Section>
</Layer>
</StateImagery>
<StateImagery name="ActiveSelection">
</StateImagery>
<StateImagery name="InactiveSelection">
</StateImagery>
</Falagard>

We only specify the vertical formatting for the new ''ImageryComponent'' because we are specifying the area to exactly match the width of the image, and thus any formatting would have no effect. ''LeftAligned'' (the default) is just fine.

Now we just need to do something in the ''ActiveSelection'' and ''InactiveSelection'' states...

== Selection ==
When the user has selected text in the ''Editbox'', either with the mouse or the keyboard, CEGUI render the selection using the two additional states '''ActiveSelection''' and '''InactiveSelection'''.

The the window is active (has focus) it will use the state '''ActiveSelection''', if if does not have focus (inactive) yet still has a selection '''InactiveSelection''' will be used.

For the selection in this look'n'feel, we'll use a single image stretched over the selection area. This image will contain plain white in the image file so we can apply any colour(s) we choose to the selection imagery.
Let's call it '''White'''.

For '''ActiveSelection''' we'll use a classic blue colour, for inactive the same, except we'll make it 50% transparent.
We can avoid a colour tag in the '''ActiveSelection''' state if we specify the colours to use directly in the ''ImageryComponent''. We'll do that to show how it works.

We'll create a new ''ImagerySection'' for this "selection brush" named '''selection'''. XML follows:

<ImagerySection name="selection">
<ImageryComponent>
<Area>
<Dim type="LeftEdge">
<AbsoluteDim value="0" />
</Dim>
<Dim type="TopEdge">
<AbsoluteDim value="0" />
</Dim>
<Dim type="RightEdge">
<UnifiedDim scale="1" offset="0" type="RightEdge" />
</Dim>
<Dim type="BottomEdge">
<UnifiedDim scale="1" offset="0" type="BottomEdge" />
</Dim>
</Area>
<Image imageset="MyImages" image="White" />
<Colours topLeft="FF26458A" topRight="FF26458A" bottomLeft="FF26458A" bottomRight="FF26458A" />
<VertFormat type="Stretched" />
<HorzFormat type="Stretched" />
</ImageryComponent>
</ImagerySection>

We use a default area that you should recognise by now. CEGUI will automatically use the right size for the selection.
The image we use is the one called '''White''' from our favorite imageset '''MyImages'''. Like always ;-)
A colour tag has been added as well to make our selection some kind of blue...
The vertical and horizontal formatting is ''Stretched'' which is generally what you would want to do in a situation like this.

We'll "call" this ''ImagerySection'' from the '''ActiveSelection''' and '''InactiveSelection''' states. In the '''InactiveSelection''' state we'll further modulate the colours used by passing a 50% transparent white. This will have the effect of using the same colour as in the active state, but make that colour 50% transparent. We could have just specified the full colour to use in each state and remove the ''Colours'' tag from the ''ImageryComponent'', but I wanted to show that multiple modulations are possible with Falagard.

The states are the last thing missing from the look'n'feel, so let's take a look at the final XML (yay :-P ).

<?xml version="1.0" ?>
<Falagard>
<NamedArea name="TextArea">
<Area>
<Dim type="LeftEdge">
<ImageDim imageset="MyImages" image="EditboxL" dimension="Width" />
</Dim>
<Dim type="TopEdge">
<ImageDim imageset="MyImages" image="EditboxT" dimension="Height" />
</Dim>
<Dim type="RightEdge">
<UnifiedDim scale="1" offset="0" type="RightEdge">
<DimOperator op="Subtract">
<ImageDim imageset="MyImages" image="EditboxR" dimension="Width" />
</DimOperator>
</Unified>
</Dim>
<Dim type="BottomEdge">
<UnifiedDim scale="1" offset="0" type="BottomEdge">
<DimOperator op="Subtract">
<ImageDim imageset="MyImages" image="EditboxB" dimension="Height" />
</DimOperator>
</Unified>
</Dim>
</Area>
</NamedArea>
<ImagerySection name="frame">
<FrameComponent>
<Area>
<Dim type="LeftEdge">
<AbsoluteDim value="0" />
</Dim>
<Dim type="TopEdge">
<AbsoluteDim value="0" />
</Dim>
<Dim type="RightEdge">
<UnifiedDim scale="1" offset="0" type="RightEdge" />
</Dim>
<Dim type="BottomEdge">
<UnifiedDim scale="1" offset="0" type="BottomEdge" />
</Dim>
</Area>
<Image type="TopLeftCorner" imageset="MyImages" image="EditboxTL" />
<Image type="TopEdge" imageset="MyImages" image="EditboxT" />
<Image type="TopRightCorner" imageset="MyImages" image="EditboxTR" />
<Image type="RightEdge" imageset="MyImages" image="EditboxR" />
<Image type="BottomRightCorner" imageset="MyImages" image="EditboxBR" />
<Image type="BottomEdge" imageset="MyImages" image="EditboxB" />
<Image type="BottomLeftCorner" imageset="MyImages" image="EditboxBL" />
<Image type="LeftEdge" imageset="MyImages" image="EditboxL" />
<Image type="Background" imageset="MyImages" image="EditboxBg" />
<VertFormat type="Stretched" />
<HorzFormat type="Stretched" />
</FrameComponent>
</ImagerySection>
<ImagerySection name="Caret">
<ImageryComponent>
<Area>
<Dim type="LeftEdge">
<AbsoluteDim value="0" />
</Dim>
<Dim type="TopEdge">
<AbsoluteDim value="0" />
</Dim>
<Dim type="Width">
<ImageDim imageset="MyImages" image="EditboxCaret" dimension="Width" />
</Dim>
<Dim type="BottomEdge">
<UnifiedDim scale="1" offset="0" />
</Dim>
</Area>
<Image imageset="MyImages" image="EditboxCaret" />
<VertFormat type="Stretched" />
</ImageryComponent>
</ImagerySection>
<b><ImagerySection name="selection">
<ImageryComponent>
<Area>
<Dim type="LeftEdge">
<AbsoluteDim value="0" />
</Dim>
<Dim type="TopEdge">
<AbsoluteDim value="0" />
</Dim>
<Dim type="RightEdge">
<UnifiedDim scale="1" offset="0" type="RightEdge" />
</Dim>
<Dim type="BottomEdge">
<UnifiedDim scale="1" offset="0" type="BottomEdge" />
</Dim>
</Area>
<Image imageset="MyImages" image="White" />
<Colours topLeft="FF26458A" topRight="FF26458A" bottomLeft="FF26458A" bottomRight="FF26458A" />
<VertFormat type="Stretched" />
<HorzFormat type="Stretched" />
</ImageryComponent>
</ImagerySection></b>
<StateImagery name="Enabled">
<Layer>
<Section section="frame" />
</Layer>
</StateImagery>
<StateImagery name="Disabled">
<Layer>
<Section section="frame">
<Colours topLeft="FF7F7F7F" topRight="FF7F7F7F" bottomLeft="FF7F7F7F" bottomRight="FF7F7F7F" />
</Section>
</Layer>
</StateImagery>
<StateImagery name="ReadOnly">
<Layer>
<Section section="frame">
<Colours topLeft="FFFFFFFF" topRight="FFDFDFDF" bottomLeft="FFDFDFDF" bottomRight="FFDFDFDF" />
</Section>
</Layer>
</StateImagery>
<StateImagery name="ActiveSelection">
<b><Layer>
<Section section="selection" />
</Layer></b>
</StateImagery>
<StateImagery name="InactiveSelection">
<b><Layer>
<Section section="selection">
<Colours topLeft="7FFFFFFF" topRight="7FFFFFFF" bottomLeft="7FFFFFFF" bottomRight="7FFFFFFF" />
</Section>
</Layer></b>
</StateImagery>
</Falagard>

That's it folks. The look'n'feel is done. Hopefully you're starting to play around with the XML and making the look'n'feel suit you (or your artist ;-) ).
Again, feel free to add comments in the discussion page.

Stay tuned for part III...

--[[User:lindquist|lindquist]] 00:41, 14 Dec 2005 (CET)

Talk:The Beginners Guide to Falagard skinning - Part II

2007-03-30T20:00:43Z

Pompei2: /* Unified Area of the caret ? */

Talk:The Beginners Guide to Falagard skinning - Part I

2007-03-29T20:10:55Z

Pompei2: /* Great ! */

Please add you feedback comments. What is good? What is bad? What is missing? etc.

--[[User:lindquist|lindquist]] 11:55, 6 Dec 2005 (CET)

== Great ! ==

Thank you very much for this, I just read it and now that i know the very basics of skinning, I can go on :)

Just one thing I noticed is a typo you made:
In the last chapter: "Colours", the little code part that states:
<Section name="label">
<ColourProperty name="NormalTextColour" />
</Section>
Shouldn't it be like this ?
<Section section="label">
<ColourProperty name="NormalTextColour" />
</Section>

--[[User:Pompei2|Pompei2]] 13:10, 29 March 2007 (PDT)

Talk:The Beginners Guide to Falagard skinning - Part II

2007-03-29T20:10:29Z

Pompei2: /* Very good */

Talk:The Beginners Guide to Falagard skinning - Part II

2007-03-29T20:10:17Z

Pompei2: /* Unified Area of the caret ? */

Talk:The Beginners Guide to Falagard skinning - Part II

2007-03-29T20:09:40Z

Pompei2: Very good

Talk:The Beginners Guide to Falagard skinning - Part II

2007-03-29T20:02:19Z

Pompei2: Unified Area of the caret ?

Talk:The Beginners Guide to Falagard skinning - Part I

2007-03-29T19:27:12Z

Pompei2: Great !

Create ImageButtons

2007-01-11T19:18:44Z

Pompei2:

If you write a GUI for a game, at some time comes the point where you want to create the most exciting kind of buttons: ImageButtons ! But care, I'm not talking about a default button frame, that has a picture instead of a text, I'm talking about ''completely'' self-drawn buttons. I've found two ways to accomplish that task, both are nice.

== Preparations ==
There are a few tasks we have to accomplish before being able to create an ImageButton.

=== Draw it ! ===
The most important thing is, of course, draw the pictures. If you don't want to accomplish this, ask your graphics artist :)
You have to draw 4 pictures/button, wich represents the four states:
#Normal: That is how the button looks like most of the time.
#Hover: This is how the button should look when the mouse comes over it.
#Pushed: When the user clicks the mouse button (and holds it down a bit) over the button, it looks like this.
#Disabled: You can imagine what this is.

This is the file we'll use for this HOWTO and as you see, i didn't ask my graphics artist to do one :p
You can find all other files (source code, data files) there too.
[[http://pompei2.cesar4.be/cegui/imgButton/]]

=== The Imageset ===
When I talk about an Imageset, I mean two files: The picture file (.tga, .png, or whatever) and the description (.imageset) file. The picture file can contain a lot of images, but it's size has to be a power of two. The description file is an xml file wich gives a name to a (rectangular) location in the picture. So you can call the location (150,150,32,32) "UnitIcon" for example.

'''An example for a .imageset file:'''
<?xml version="1.0" encoding="UTF-8"?>

<Imageset Name="THEButton" Imagefile="THEButton.png" >
<Image Name="btnNormal" XPos="0" YPos="0" Width="64" Height="20" />
<Image Name="btnHover" XPos="0" YPos="20" Width="64" Height="20" />
<Image Name="btnPushed" XPos="0" YPos="40" Width="64" Height="20" />
<Image Name="btnDisabl" XPos="0" YPos="60" Width="64" Height="20" />
</Imageset>
We will use this imageset in our examples. It defines four named images: btnNormal, btnHover, btnPushed and btnDisabl (saved in the file "THEButton.png"). The whole imageset is called "THEButton" and saved in a file named "THEButton.imageset".

How to use this imageset now ? This is very simple, you just have to do this in your initialisation code:
// Load the THEButton Imageset that has the pictures for our button.
CEGUI::ImagesetManager::getSingleton().createImageset( "THEButton.imageset" );
That's all ! Of course, you should do this in a try/catch block.

If, for some wicked reason, you want to do something in code with this imageset, you can either save the pointer that the function above returns, or you just get that pointer if you know the name of the imageset (what you usually do), using this function:
CEGUI::Imageset *m_pImageSet = CEGUI::ImagesetManager::getSingleton().getImageset( "THEButton" );

Enough about imagesets.

== The programmer's job ==
Now we can create the button itself (in two different ways):

=== The first way: mainly in code ===
One way is to create the button in code, you usually do this if you only know wich button to display at runtime. Maybe a strategy game is the best to illustrate this. Imagine you have the buttonspanel, a place on screen with an array of buttons. The buttons that are present there depend on something (like wich unit is currently selected or so). The first thing you have to do, is not in code. Create one layout file for every button. The file should look somewhat like this:

'''Content of button1.layout version 0.1'''
<?xml version="1.0" encoding="UTF-8" ?>
<GUILayout>
<Window Type="TaharezLook/ImageButton" Name="btnNewGame">
<Property Name="UnifiedPosition" Value="{{0,0},{0,0}}" />
<Property Name="UnifiedSize" Value="{{0,64},{0,20}}" />
<nowiki>
</nowiki>
<Property Name="NormalImage" Value="set:THEButton image:btnNormal" />
<Property Name="HoverImage" Value="set:THEButton image:btnHover" />
<Property Name="PushedImage" Value="set:THEButton image:btnPushed" />
<Property Name="DisabledImage" Value="set:THEButton image:btnDisabl" />
<nowiki></nowiki>
</Window>
</GUILayout>

If you have an imagebutton but you want it to have a caption, you could write this kind of layout file:

'''Content of button1.layout version 0.2'''
<?xml version="1.0" encoding="UTF-8" ?>
<GUILayout>
<Window Type="TaharezLook/ImageButton" Name="btnNewGame">
<Property Name="UnifiedPosition" Value="{{0,0},{0,0}}" />
<Property Name="UnifiedSize" Value="{{0,64},{0,20}}" />
<nowiki>
</nowiki>
<Property Name="NormalImage" Value="set:THEButton image:btnNormal" />
<Property Name="HoverImage" Value="set:THEButton image:btnHover" />
<Property Name="PushedImage" Value="set:THEButton image:btnPushed" />
<Property Name="DisabledImage" Value="set:THEButton image:btnDisabl" />
<nowiki></nowiki>
<Window Type="TaharezLook/StaticText" Name="btnNewGame_text__">
<nowiki>
</nowiki>
<Property Name="UnifiedPosition" Value="{{0,0},{0,0}}" />
<Property Name="UnifiedSize" Value="{{1,0},{1,0}}" />
<nowiki></nowiki>
<Property Name="FrameEnabled" Value="False" />
<Property Name="BackgroundEnabled" Value="False" />
<nowiki></nowiki>
<Property Name="HorzFormatting" Value="WordWrapCentred" />
<Property Name="VertFormatting" Value="Middle" />
<nowiki>

</nowiki>
<Property Name="Disabled" Value="True" />
<nowiki></nowiki>
<Property Name="Text">New game</Property>
</Window>
</Window>
</GUILayout>

This adds a child window of type StaticText, with no border and background, that takes all the place in the button, so we can center it. If your caption has to be not centered, play with the values.

A problem that comes up now, is that if the user clicks on the button, the click will be absorbed by the StaticText, and won't reach the button. That's bad. I searched around and found the following two propertys:
<Property Name="MousePassThroughEnabled" Value="True" />
<Property Name="DistributeCapturedInputs" Value="True" />
But both didn't seem to work as expected, I asked the forums and lindquist told me that "If all you want is a simple label added to the ImageButton then adding a TextComponent in the looknfeel is a much cleaner solution.". He is probably right, but I didn't struggle with looknfeels yet. If you achieved this, you can tell me or add a chapter to this wiki :)

The solution he suggested (and the only one wich worked, if i remember correctly, is disabling the staticText (like in the complete code written above)

<Property Name="Disabled" Value="True" />

Now all you need to do to load and show the button are the following four lines of code.

CEGUI::Window *w = CEGUI::WindowManager::getSingleton().loadWindowLayout( "button1.layout" );
rootWin->addChildWindow( w );
w->setPosition( CEGUI::UVector2( CEGUI::UDim(0.5f,-32.0f), CEGUI::UDim(0.5f,-10.0f) ) );
w->setVisible( true );
Supposing rootWin is your current root window, or any other window you want to put the button in.
We set the position to be the center (0.5f) minus the half the height/width of the button, so the button is really centered.
Of course, you can do everything else you want before (and while) showing the button.

That's it ! now you can work with the button however you want :)

=== The second way: Let the power of layout guide you ===
I suppose you read the first way, because they are very similar and I won't rewrite the whole code here. The main difference is that if you like layouts, you'll already have declared all your windows in layout files. The the "'''Content of button1.layout version 0.2'''" won't be alone in a layout file of it's own, but it will be in your already existing layout files.
You still have to load the Imageset. I Provided a sample, named imgButtonSample.layout

That's it ! If you got suggestions, corrections or whatever feedback, just tell me.
----

--[[User:Pompei2|Pompei2]] 11:18, 11 January 2007 (PST)

Tutorials

2007-01-11T16:18:38Z

Pompei2:

=== CrazyEddie's Beginner Guides ===
* [[The Beginner Guide to Getting CEGUI Rendering]] - How to initialise CEGUI to render properly.
* [[The Beginner Guide to Loading Data Files and Initialisation]] - How to load some data files and perform basic system initialisation.
* [[The Beginner Guide to Creating a CEGUI Window]] - How to create a simple window and get it on screen.
* [[The Beginner Guide to Injecting Inputs]] - How to inject inputs into CEGUI and get interactive.

=== Scripting with CEGUI ===
* [[Getting Started with Lua and CEGUI]] - How to initialise CEGUI with a Lua script module and configuration file.
* [[Handling Events from Lua]] - How to load Lua script files and bind CEGUI events to Lua functions.
* [[Writing CEGUI scripts]] - Code snippets
* [[Adding LuaScriptModule to Sample_FirstWindow]] - Experience adding scripting to an existing sample.
* [http://www.gpwiki.org/index.php/Crazy_Eddies_GUI_System:Tutorials:Creating_a_scriptable_interface_using_CEGUI Creating a scriptable interface using CEGUI]

=== Window System Examples ===
* [[Using CEGUI with SDL and OpenGL]] - Guidelines on how to get SDL, OpenGL and CEGUI running together.
* [[Using CEGUI with Producer and OpenGL]] - Guidelines on how to render and inject input to CEGUI from the Producer API.
* [http://artis.imag.fr/Membres/Xavier.Decoret/resources/CEGUI/ Using CEGUI with Qt/QGLViewer]
* [[Using CEGUI with GLUT]] - Some tips on using OpenGL's GLUT with CEGUI.

=== Extending CEGUI ===
* [[Using Expat XML parser within CEGUI]] - How to add support for another XML parser.

=== Skins - Tutorial For Artists ===
* [[Creating Skins]] - Extra notes for artists on how to create skins.
* [[The Beginners Guide to Falagard skinning - Part I]] - Learn by doing a Button.
* [[The Beginners Guide to Falagard skinning - Part II]] - More Falagard fun, this time with the Editbox.

=== Overviews ===
* [[Overview of GUI files]] - A quick introduction to all the XML files used by CEGUI.
* [[Overview of resource system enhancements in 0.5.0]] - Introduction to enhancements made for the 0.5.0 release.

=== Miscellaneous HOW-TOs ===
* [[Create ImageButtons]] - A few different ways to create image buttons.