Difference between revisions of "GUI Themes/Specs"
(More on evaluation precedence) |
(Move sections precendence into evaluation precedence) |
||
Line 13: | Line 13: | ||
* [640xY] -- could be used for 640x400 and 640x480 | * [640xY] -- could be used for 640x400 and 640x480 | ||
* [640x480] -- could be used for 640x480 only | * [640x480] -- could be used for 640x480 only | ||
=== Expressions === | === Expressions === | ||
Line 152: | Line 138: | ||
== Evaluation precedence == | == Evaluation precedence == | ||
Within one section everything is computed left to right down to top. No forward references are allowed. Only exception is aliases which can refer to not yet defined variables and widget properties, but at time of useage those variables should be defined, otherwise you will get an error. | |||
Currently any error in evaluation will lead to error() and ScummVM will be closed. So be careful, especially with built-in theme. | Currently any error in evaluation will lead to error() and ScummVM will be closed. So be careful, especially with built-in theme. | ||
On each resolution change all user-defined variables and aliases get cleared and all sections get recomputed. When sections get loaded for a single resolution, all of them are kept, so you can specify a generic [XxY] scheme and then overwrite only some widgets, thus simplifying whole thing. | On each resolution change all user-defined variables and aliases get cleared and all sections get recomputed. When sections get loaded for a single resolution, all of them are kept, so you can specify a generic [XxY] scheme and then overwrite only some widgets, thus simplifying whole thing. | ||
Sections loading order is always the same. For resolution 640x480 it is: | |||
# Built-in theme | |||
## [XxY] | |||
## [640xY] | |||
## [640x480] | |||
# Custom theme | |||
## [XxY] | |||
## [640xY] | |||
## [640x480] | |||
Only present sections are loaded. If section is not defined, no error message is generated | |||
== Widget name conventions == | == Widget name conventions == |
Revision as of 03:35, 7 March 2006
GUI Themes config file format
Overview
We always have a built-in theme. It is used when there is no external .ini file. For simplicity it uses exactly same format as external .ini but is defined in Theme::_defaultConfigINI string in gui/theme-config.cpp file.
Config file consists of at least one section. These sections can override one another. This is used to make a slight alteration of base theme possible without duplicating all element whose position is not changed.
Section names
They are defined with this regexp: (X|[0-9]+)x(Y|[0-9+]+). I.e. possible names are:
- [XxY] -- universal one which can be used for any resolution
- [640xY] -- could be used for 640x400 and 640x480
- [640x480] -- could be used for 640x480 only
Expressions
To add most flexibility arbitrary arithmetic expressions can be used for specifying any element. Allowed operations are '(', ')', '+', '-', '*', '/'. unary '+' and unary '-'. Atoms are either number or symbolic names.
Built-in Constants
Currently there are these built-in constants defined:
- kButtonWidth
- kButtonHeight
- kSliderWidth
- kSliderHeight
- kBigButtonWidth
- kBigButtonHeight
- kBigSliderWidth
- kBigSliderHeight
These correspond to constants defined in gui/widget.h file. There is no restriction on constants names.
Built-in Variables
Built-in variables are symbolic names for ScummVM variables whose value is determined at run-time. These are:
- w -- current GUI width
- h -- current GUI height
Defining widget positions
Widgets are specified by following construction:
widget_name=X Y [W H]
X, Y, W and H are whitespace-delimited expressions. W and H are optional.
This construct effectively defines
- widget_name.x
- widget_name.y
- widget_name.w
- widget_name.h
If W and H are present, also these get defined:
- widget_name.x2 = widget_name.x + widget_name.w
- widget_name.y2 = widget_name.y + widget_name.h
Example:
chooser_headline=10 6 (w - 2 * 16) (kLineHeight)
Widget properties
Above mentioned constructions with dots are called widget properties.
Example:
chooser_list.x
Special variables
Special variable is:
* self
It is reference to current widget special variables, i.e. .x, .y, .w and .h
Example:
chooser_list=10 (6 + kLineHeight + 2) (w - 2 * 16) (h - self.y - buttonHeight - 12)
Denote self.y which equals to computed value of (6 + kLineHeight + 2).
You cannot use these references forward, i.e. refer to .w in .x. They get defined from left to right.
Defining variables
Example:
def_kLineHeight=16 * 2 OneThirdWidth=w / 3
variable kLineHeight gets value 32. OneThirdWidth will be GUI width divided by 3. Definitions with 'def_' prefix have a special meaning and get skipped with USE keyword (see below).
Defining aliases
You can define alias to any symbolic atom, i.e. constants, variables and widget properties.
Example:
set_headerBottomX=headline.x2
Now you can use headerBottomX everywhere.
Special alias
set_parent=chooser_list
It sets 6 aliases for each widget property, i.e.
- parent.x = chooser_list.x
- parent.y = chooser_list.y
etc for .w, .h, .x2 and .y2
Example:
set_parent=tabMidi midi_checkbox=(parent.x + 10) (parent.y + 20) roland_checkbox=midi_checkbox.x (parent.y + 50)
USE keyword
You can request loading of some particular section at any time within another section. But all variable definitions with def_ prefix get skipped. If you want to define a variable, use plain VAR=VAl construction.
Example:
[640xY] def_buttonHeight=kBigButtonHeight def_kLineHeight=16 listW=(w - 2 * 16) chooser_headline=10 6 listW (kLineHeight) chooser_list=10 (6 + kLineHeight + 2) listW (h - self.y - buttonHeight - 12) [320xY] def_buttonHeight=kButtonHeight def_kLineHeight=9 use=640xY
In this example for 320xY resolution chooser_headline and chooser_list will be loaded from [640xY] section, though buttonHeight and kLineHeight will be different. listW will get the value.
Evaluation precedence
Within one section everything is computed left to right down to top. No forward references are allowed. Only exception is aliases which can refer to not yet defined variables and widget properties, but at time of useage those variables should be defined, otherwise you will get an error.
Currently any error in evaluation will lead to error() and ScummVM will be closed. So be careful, especially with built-in theme.
On each resolution change all user-defined variables and aliases get cleared and all sections get recomputed. When sections get loaded for a single resolution, all of them are kept, so you can specify a generic [XxY] scheme and then overwrite only some widgets, thus simplifying whole thing.
Sections loading order is always the same. For resolution 640x480 it is:
- Built-in theme
- [XxY]
- [640xY]
- [640x480]
- Custom theme
- [XxY]
- [640xY]
- [640x480]
Only present sections are loaded. If section is not defined, no error message is generated
Widget name conventions
Widget names are in form:
dialog_widget
where dialog_ is dialog name, and widget is a distinguishable name within that dialog. Be discreet and give meaningful names.
Example:
chooser_headline chooser_list