Suggestion: Manifest schema property to include "useInName"

[nytamin]

Proposal:

Add a useInName?: boolean property to the manifest schema properties. When useInName = true, this indicates that the value of the property should be included when labelling a graphics in a GUI.

Motivation:

When working on implementing OGraf support into Sofie TV Automation, I found that this would have been nice to have, in order to display meaningful labels to the user (and omit not-so-useful data).

Example:

{
    "$schema": "https://ograf.ebu.io/v1/specification/json-schemas/graphics/schema.json",
    "id": "title",
    "name": "Title screen",
    "main": "title.js",
    "schema": {
        "type": "object",
        "properties": {
            "mainText": {
                "type": "string",
                "title": "Main Title text",
                "useInName": true
            },
            "titleColor": {
                "type": "string",
                "default": "#d32f2f"
            },
            "titlePosition": {
                "type": "string"
            },
        }
    }
}

In this example, mainText would be useful to display in a gui (eg "Title screen: Johan Nyman"), whereas the color and position is not.

[didikunz]

I like the idea and would support that change.

But I would suggest to do it the other way around: Name the property "hidden" and default it to false. So every field would be included, except the ones that are explicitly hidden. Would also provide some backward compatibility to the way it is now.

[dvdeurse]

LiveOS has a similar boolean property for parameters called visible. It is used in the UI inside the graphics playlist application. When set to true, the template parameter will be shown inside the playlist item. Note that we can still overwrite this when editing the playlist item, so the property in the manifest only serves as a default value. It is currently implemented as a vendor-specific field.

I never thought about proposing this field into this group as I thought it was very specific to our UI, but clearly it isn't :-). I agree with @didikunz though and would inverse it to keep backwards compatibility. In that case, 'hidden' seems to be a good name.

[nytamin]

notes from meeting 2026-02-18: Adding a hidden property would probably be best, as it best retains "backwards compatibility".