...
Settings are configurations for your exhibit, and can be thought of as two way communications between the Gumband cloud and your exhibit. Settings will be the most unique between exhibits and could configure anything from text copy to the RPMs of a motor. Settings are also configured through the manifest:
| Code Block | ||
|---|---|---|
| ||
{export const MANIFEST = { " manifest": { "statuses": [], "controls": [], "settings": [ { "id": "header", "type": "TextInput", "display": "Header Copy", "default": "Gumband Demo", "order": 0 }, { "id": "subheader", "type": "TextInput", "display": "Subheader Copy", "default": "Digital Signage", "order": 1 }, { "id": "body", "type": "TextInput", "display": "Body Copy (separate by | for new paragraph)", "default": "Gumband is an interactive experience tool", "order": 2 }, { "id": "main-image", "type": "FileSelection", "display": "Image Asset", "order": 3 } ] } } |
would configure settings for the following exhibit instance in the Gumband UI:
...
Sometimes, an exhibit will need a way to introduce more settings at runtime. This typically occurs when it needs to integrate with a variable number of similar external devices, and therefore it needs to be able to manage a variable number of a group of settings. For example, consider an exhibit that could play music from a number of sources, and suppose there was a requirement that the number of sources could change over time. Let’s assume for simplicity that these music sources are all managed by an external system (e.g. QSYS) and that all we need to know are the IDs of all of the music sources. We would start by adding a SettingsList setting type in the manifest:
| Code Block | |||
|---|---|---|---|
| |||
export const MANIFEST = {
manifest: {
settings: [
{
"id": "audio-sources",
"type": "SettingsList",
"display": "Audio Sources",
"schema": [
{
"id": "source-id",
"type": "TextInput",
"display": "Source ID",
"order": 0
},
{
"id": "select-source",
"type": "Toggle",
"display": "Select Source",
"order": 1
}
]
}
]
}
} |
...