How to properly use different looknfeels

[rgrieder]

Hi there,

I'm currently studying as much of CEGUI as possible to make a proper integration into a 3D game. We've been using CEGUI for like two years now, but the integration was rather poor.

So now I've gotten to the falagard skinning system and I'm asking myself what I have to do to have multiple looknfeels. Say we use CEGUI for menus and for the HUD. And I would like to use different looknfeels for each of them. And these should be configurable (not at run time).

I've come up with a rather hacky method that requires two *.scheme files. The first (called MenuWidgetsTaharez.scheme) defines the falagard mappings to window types called "MenuWidgets/Button". But suppose I want a different look, I would simply like to replace that MenuWidgetsTaharez.scheme by MenuWidgetsMyLook.scheme.
In the new file I would then change the mapping from e.g. LookNFeel="TaharezLook/Button" to LookNFeel="MyNewLook/Button".

This way I can simply use "MenuWidgets/WindowType" and "HUDWidgets/WindowType" in my layout files.

That seems very reasonable to me. But there is an implementation problem: TaharezLook.looknfeel addresses child windows by "TaharezLook/MyWidget" of course. And since I don't define any of these types I get an exception. Though I was able to resolve this issue by using window type aliases for each window type.
Unfortunately I have to do this in two files or otherwise the loader would complain that the types from the falagard mappings don't exist (probably because the types only get updated after the scheme file has been loaded).

However something tells me I've completely misunderstood the concept of the falagard skinning system... ^^
Can anybody give me a hint on how to properly implement my desired behaviour?

Using CEGUI 0.6.2 on Windows XP, compiling with Visual Studio 9 SP1. Though our project supports both windows (msvc, mingw) and linux (gcc).

EDIT: I guess it would be better to do the aliases the other way round. It makes a bit more sense

[CrazyEddie]

Hi,

Basically you're half way there already, though are missing one vital piece of the puzzle

You'll likely to want to make use of the scheme system's window type aliasing ability. The prerequisite set up is basically what you already have, you load the scheme's with the looknfeels that you might want to use (though double check that the scheme's do not contain double-entries for resources such as imagesets and fonts, since this is not allowed under 0.6.2), and you need to define your layouts with neutral names, such as the 'MenuWidgets' and 'HUDWidgets' prefixes already suggested.

The missing piece is to define additional scheme files that contain WindowAlias mappings from those neutral names to specific names in the 'target' scheme. For example:

Code: Select all

<?xml version="1.0" ?>
<GUIScheme Name="TaharezLookAliases">
   <WindowAlias Alias="MenuWidgets/Button" Target="TaharezLook/Button" />
   <WindowAlias Alias="MenuWidgets/Checkbox" Target="TaharezLook/Checkbox" />
   <WindowAlias Alias="MenuWidgets/Editbox" Target="TaharezLook/Editbox" />
   <WindowAlias Alias="MenuWidgets/FrameWindow" Target="TaharezLook/FrameWindow" />
   ...
</GUIScheme>

HTH

CE.

[rgrieder]

Thank you for the reply.

The missing piece is to define additional scheme files that contain WindowAlias mappings from those neutral names to specific names in the 'target' scheme. For example:

Yep, just figured that out. I already adjusted Taharez, Windows and Vanilla LookNFeels to provide a basic set of widgets using Taharez as backup if not available.

(though double check that the scheme's do not contain double-entries for resources such as imagesets and fonts, since this is not allowed under 0.6.2)

Does that cover multiple files too? So when I have to use the Taharez ImageSet in 3 schemes and then load all three, is that legal (it does load)?

One more thing: I seem to be having trouble with the Vanilla skin because of missing property definitions:

Code: Select all

CEGUI::UnknownObjectException in file CEGUIPropertySet.cpp(124) : There is no Property named 'HoverImage' available in the set.

Is that a known issue or am I doing something wrong? Because the TaharezLook.looknfeel does contain the PropertyDefintions whereas Vanilla.looknfeel doesn't.

[CrazyEddie]

when I have to use the Taharez ImageSet in 3 schemes and then load all three, is that legal (it does load)?

Thinking about it, I think it will be fine - the scheme checks and only loads if the referenced resource if it's not already present in the system (not sure what I was thinking of earlier).

One more thing: I seem to be having trouble with the Vanilla skin because of missing property definitions:

Code: Select all

CEGUI::UnknownObjectException in file CEGUIPropertySet.cpp(124) : There is no Property named 'HoverImage' available in the set.

Is that a known issue or am I doing something wrong? Because the TaharezLook.looknfeel does contain the PropertyDefintions whereas Vanilla.looknfeel doesn't.

This is a side effect of differences in looknfeel, such items are not considered "missing" as such. Each of the example looknfeel definitions contains certain items or definitions that the others do not - this is not considered an issue, bug or omission; it serves as an example that the system is not rigid in such requirements - although this can cause some problems when trying to just swap one for another. Consider also, for example, the fact that when using the unmodified sample looknfeel definitions, in TaharezLook the slider is vertical, in WindowsLook it is horizontal and Vanilla has no separate slider at all.

It's left to the developer to ensure the looknfeel definitions used contain any 'common' items and definitions that they will be needing.

HTH

CE.

[rgrieder]

Well, I really do understand that.
But in fact, I was referring to lines like

Code: Select all

<Property name="HoverImage" value="set:Vanilla-Images image:ScrollRightArrow" />

in Vanilla.looknfeel that create the error I mentioned above. When I add a PropertyDefintion it works of course.

[CrazyEddie]

Ah right, yes these issues were fixed in the stable v0-6 branch back in March '09. If you need to stay on the 0.6.x line, you might consider dumping 0.6.2 and grabbing the v0-6 branch code instead, because it contains some other important bug fixes also.

CE.

[rgrieder]

Ok, thanks a lot. I guess I'll have a look at the Subversion logs then.