Skip to content
Closed
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
2 changes: 1 addition & 1 deletion README.md
Original file line number Diff line number Diff line change
Expand Up @@ -373,7 +373,7 @@ Let's the user pick a color.
}
```

The value is stored as a string on the form "#RRGGBB", eg `"#61138e"`.
The value is stored as a string on the form "#RRGGBB", eg `"#61138e"`. An optional alpha part could be added, like #AARRGGBB. This is seldom used, but make sense to be supported.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Having the option to pick color+alpha would be good 👍 , but because it changes the underlying data type, it should be a separate gddType. I suggest we create a separate PR for this.


### Percentage

Expand Down
5 changes: 5 additions & 0 deletions doc/appendix/playout-options.md
Original file line number Diff line number Diff line change
Expand Up @@ -41,6 +41,11 @@ _Note: All of the properties inside of `gddPlayoutOptions` are optional._
/** The default / suggested layer to play on */
"layer"?: number

/** A list of the commands supported by the template, can be displayed as buttons */
"commands": ["play", "next", "stop", "update", "(custom invokes)"]
/** A template should support "play" and "stop" as a minimum. Some templates are not meant to be updated when already */
/** played, so they shall not support "update". Some templates support invoke comands like "show", "hide", "showOvertime" */
/** or anything else. These commands can be used to render (or enable/disable) buttons in the UI. */
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't think we should be aiming to support existing templates in this specification, so I don't think this is the way to go.

A larger question though is: "how the templates should work"?
The play(), next(), stop(), update() pattern is a CasparCG one.
Is that something we should add to the specification in general? Or should that be added to the specification, but under for CasparCG-templates only?

},
}
}
Expand Down