The name of the "Show Controls" setting is misleading + a real "Show/Hide Controls" setting is required

Opinions?

51% for:
- Fix the labels from the existing "controls" formatter setting => "Show original player controls"
- Add another setting "Hide Controls" to set the custom class as described in the issue description + add the required CSS code

Before implementing anything here, I think we need to come to a consensus what's expected and what should be handled (in the UI) or if this is essentially a vidstack bug.

I think when using Vidstack, we always want to use the Vidstack controls and I'd expect Vidstack to hide the native controls. Adding a further checkbox would delegate this confusion to the user, so I'd vote to either report this as bug to Vidstack and see what they say or (at least for now) set the attributes in a way that isn't confusing, so the user only controls the vidstack controls and if they are OFF, other controls are also hidden.

Yes, exactly. WE (as DROWL company) never want to have the native controls when using Vidstack.

We could report this to Vidstack - this property name is definitely really, really bad, but I am pretty sure IF this will be solved, it will be in a new major release. So we are blocked on this issue for a long time. So as suggested above, I would prefer to leave the technical field name and just rename the label. Plus add another setting + css code to hide the Vidstack controls. We need to hide the controls for background videos, or for custom implementations where we have our own play/pause button.

@lrwebks: Ok let's do it like this, as just discussed with @thomas.frobieter:

Replace the current controls checkbox with a "Controls" select with the following options:
- Hide controls
- Show native controls
- Show vidstack controls

()Maybe in the future we'll have further ones like "Show XX controls on hover"...

This needs no update hook, as the module is not used anywhere yet.

Note, that we do NOT provide the controls setting. This is a setting provided by the parent formatter "FileMediaFormatterBase" (at least for the "VidstackPlayerVideoFormatter", "VidstackPlayerRemoteVideoFormatter" extends FormatterBase, so we simply copied and pasted the setting from "FileMediaFormatterBase"). Meaning we would need to unset that setting in VidstackPlayerVideoFormatter, remove it in VidstackPlayerRemoteVideoFormatter and provide a setting with a similar name (e.g. "overlay_controls") in the Formatter Trait.

We could also modify the existing setting, but it might mess with the parent methods.

Thanks @grevil! Yes I think we should unset it, at least in the UI. In the backend we could eventually map it...

Ok here are the new settings as discussed with @thomas.frobieter, to implement as checkboxes.

Hide controls [hide]
Show vidstack controls [show_vidstack]
Show vidstack controls (on hover) [show_vidstack_hover]
Show native controls [show_native]

Should work as expected now!

LGTM, just one question for @thomas.frobieter - and ready for his testing and CSS implementation.

I can't seem to find any code unsetting "controls", or am I missing something here? As already stated before in #8 "controls" is not defined by us, but comes from "FileMediaFormatterBase", meaning it needs to be unset explicitly in the "VidstackPlayerVideoFormatter".

But I am generally confused, why we are doing so much fuss about this? IMO, we should just adjust the label of "controls" from "Show playback controls" to "Use native controls" and overwrite the default from TRUE to FALSE and be done with it.

@grevil, it is not necessary to unset the controls setting that is passed down from FileMediaFormatterBase, as we no longer actually process it. Instead, we use our new controlsDisplay setting and pass that down to the player as data-controls. So an override with no changes to the following outcome would be unnecessary.