The Theming Engine

[Dave]

I have just committed an initial version of a theming engine to CVS.

Here's how it works:

- themes are stored in data/themes, one theme per file.
- themes allow flexible configuration of how everything is laid out on-screen
- format of a theme is:

Code: Select all

[theme]
    name=<name>
    [resolution]
    width=<x>
    height=<y>
        ....'content tags'....
    [/resolution]
    ...more resolution tags...
[/theme]

- the [resolution] tags are scanned until the first one which is of the same or lower resolution than is currently being used is found, and this is used as our theme. This allows us to define themes to work differently on different resolutions, and will allow us to support both high and low resolutions elegantly.
- the 'content tags' define where everything goes on-screen. The most common content tag is the 'main_map' tag, it has the following format:

Code: Select all

[main_map]
rect=x1,y1,x2,y2
xanchor=left|right|fixed|proportional
yanchor=top|bottom|fixed|proportional
[/main_map]

The purpose of the 'main_map' tag is to define where the main game display (i.e. all the hexagons and units) is displayed. The rect field defines the rectangle the map is displayed on. The rectangle is given for a 1024x768 display -- the game's "canonical" resolution.

xanchor and yanchor control the behavior of how this rectangle changes as the resolution changes.

- A rectangle anchored to the left will have its distance from the left side of the screen always remain the same, while changes in the resolution will change its size by the same amount.
- A rectangle anchored to the right will have its size always remain the same, as well as its distance to the right side of the screen.
- A rectangle that is fixed will have its co-ordinates in that axis remain constant
- A rectangle that is proportional will have its co-ordinates multiplied by the ratio of the resolution being used to the canonical resolution.

Other common tags are:

- 'mini_map': same format as 'main_map', determines where the mini map is displayed
- 'label': displays a text label on screen. has an attribute 'text' which contains the id of the translatable string that is displayed for the label. Has an attribute 'image' which can be used to display an icon instead of text.
- 'panel': displays an image as a panel on-screen. Has an attribute 'image' which is the image used for the panel
- 'status': this tag contains many other tags, which determine where other game statistics, such as the current turn, and a description of selected units go. For instance, the time_of_day tag will determine where the time of day image goes.

I will document all this more exhaustively later. For now I recommend people look at data/themes/default.cfg for an idea.

I am still going to add support for buttons and menus - to allow the theme to set where buttons are placed, and to allow the items in menus to be theme-customizable.

I do even have possible plans to support transperant and non-rectangular panels

Comments are welcome.

David

[charlieg]

Why not use something that already has all this and can be themed to meet Wesnoth's needs?

I can think of a few, although the first that comes to mind is Picogui. Another possibility might be XWT which supports SVG but isn't currently as usable as Picogui.

[yawningdog]

charlieg: I don't think Dave will be thrilled at the idea of rewritting all the GUI code. Besides, the work is already done, so I can't see the point on migrating the whole codebase to a new toolkit (and don't forget library dependencies).

Oh, I forgot. Don't mention SVG when Dave's around, it drives him mad. And just curious, XWT looks interesting, but how does it apply to Battle for Wesnoth? Looks like a web application framework a la XUL to me.

[charlieg]

Don't mention SVG when Dave's around, it drives him mad.

How come?

And just curious, XWT looks interesting, but how does it apply to Battle for Wesnoth? Looks like a web application framework a la XUL to me.

XWT is a UI toolkit for creating remote UIs. These are usually web applications. We are also working on a way to apply it to local applications. It is possible, but there's work to be done on that front.

[Dave]

Don't mention SVG when Dave's around, it drives him mad.

How come?

SVG in itself doesn't make me mad as such, it just makes me mad how software projects, especially Free software projects, develop their project using one technology, and then half way through switch to other technologies.

The technology used for Wesnoth has been chosen, and we will stick to it. Anything else will slow us down far too much to be worth it. That doesn't mean I think the technologies we use are necessarily the best, but sticking with them is the quickest and best way to develop the game further.

David