Question on layouts and schemes

[Speedo]

One of my goals in my current project is to allow users to make their own skins (schemes), drop them in and use them with out having to actually modify the various menu layout files by changing settings in a game menu.

Considering that the layouts specify the scheme used by a particular gui object, what is the best way to accomplish this? Can the scheme used by a particular window be changed after it has been loaded? Or am I looking at writing my own loader that reads the layout xml, modifies the scheme information appropriately and then passes the data on to a GUILayout_xmlHandler? Any other suggestions?

[CrazyEddie]

Hi,

First, some things to hopefully save confusion further down the line:
- A 'skin' is a set of WidgetLook definitions usually defined in a looknfeel specification.
- A 'scheme' is a collection of related resources and a set of named definitions to map WidgetLooks to window types.

Skins can be changed at runtime (at least beginning with the 0.6.x series of releases) via the Window::setFalagardType member function; this is how the CELayoutEditor is able to switch skins, so looking at how that's done is perhaps the best example; it's slightly complicated and involves taking a snapshot of current properties, setting the new 'look' and then restoring the window state. Obviously you need to be careful how you handle 'missing' items - i.e. if one skin definition contains items another does not. This approach can be done on-the-fly and is more suited to 'skin' WidgetLook based switching.

Alternatively there is the window type aliasing system, which allows you to map types to any other type. So if you created a set of aliases from, say "Generic/<widget_type>" to the "real" types, but in the layouts use the "Generic" prefixed versions, the final type used will be whichever type was aliased at the time. Obviously this prevents on-the-fly switching, though does offer a means to 'default' types that are missing. This approach is more suited to 'scheme' based switching.

Both approaches are potentially large topics, so you might want to decide which one is best suited and - if needed - come back for more assistance and/or examples

CE.

[Speedo]

Interesting. Never noticed the aliasing ability before, it definetly sounds like the better option.

[CrazyEddie]

I think it's probably one of the least known, and little used areas of the system.

[Speedo]

I haven't had time to start implementing this yet (whose bright idea was this real life thing, anyway?), but another thing that crossed my mind. How do the alias handle duplicate names? Say we have everything in the game aliased through something like "GameGui/[...]". We load up the game with TaharezLook as the active scheme. The user goes into the options menu and changes the scheme to something else. Will the aliases in the new scheme just overwrite those that were loaded by TaharezLook? Does TaharezLook need to be unloaded first?

[CrazyEddie]

Aliased types maintain a 'stack' - if new aliases are defined without the prior alias being removed, the new alias will supersede the old one for future windows created. If you subsequently delete / remove the 'new' alias definition, the previous definition then becomes active again (for subsequent windows created).

CE.