Create a settings menu for the control bar

[paladox]

Currently any user-configuration for features added by plugins require new buttons on the control bar. We should have settings menu that allows plugin authors to add configuration options. And we may decide to add internal options to it, like language selection.

Original Title & Description

Suggestion: Create a menu that plugins can add the different things

Hi please create a menu like kaultra player does where some of the code can go for plugin so that there isent all the room taking on the control bar. Something like credits can go there. A download button. And changing resolutions can go there.

[heff]

I've been thinking about this for a while now and do think we should add one. It's just not a small effort to put it together in a way that's configurable by external plugins. If you'd be interested in helping by building some proof of concepts, please do.

In the mean time I'll confirm the feature.

[Fruitsapje]

@nickygerritsen and I have been thinking about a solution for the settings menu. We already have quite a lot of menus, so we would like to create something and I think we can do it in such a way we can do it in a PR to video.js

What we would want is a simple way to put plugins in the settings menu without the need of writing a new plugin for just adding a submenu.

As said before by default the settings menu will not be used (in video.js 5), but it can easily be enabled in the options, like this:

videojs('someid', {
  controlBar: {
        children: [
            'playToggle',
            'muteToggle',
            'volumeControl',
            'currentTimeDisplay',
            'timeDivider',
            'durationDisplay',
            'liveDisplay',

            'flexibleWidthSpacer',
            'progressControl',

            'settingsMenuButton': {
                entries : [
                    'subtitlesButton',
                    'captionsButton',
                    'playbackRateMenuButton',
                    'qualityMenuButton'
                ]
            },
            'fullscreenToggle'
        ]
    },
};

Now we need to create a SettingsMenuButton in the control-bar folder. Obviously this should extend the default MenuButton. This file on its own won't be much different from other MenuButtons like PlaybackRateMenuButton. The createmenu() function will loop over the entries and create a SettingsMenuItem for each, passing the name of the entry (i.e. subtitlesButton) as an option.

Because we want to be able to render menus as submenus, the SettingsmenuItem will be needing more changes compared to other menuItem classes. Our idea is that each entry item has two labels: one for the type and one with the currenct value (only if the entry is a menu itself). For example the subtitles submenu will be "Subtitles: off". We think creating the submenu can be done by just constructing the menubutton object (e.g. subtitlesButton), but not adding it as a direct child. This will then not add the el() of the submenu button. We will (manually) add the el() of the buttons .menu, which will add the submenus menuitems (and update them accordingly).

We think we can use the controlText of the original button (e.g. captionsbutton) for the "left label" (i.e. the name). The right one should be the value, which there is currently no easy way to get. One option would be to loop over the submenus menu.childen_[...].options_ and see which one is selected. However this might be strange for some menu items. For example the captions submenu might then display as "Captions: captions off" and I think "Captions: off" would be better?
If an entry is not a subclass of MenuItem, only the left label will be shown, which is then an action. For example if the fullscreen button is placed in the settings menu, it will display "Fullscreen" or "Non-Fullscreen"
Does this proposal fit the wishes videoJS has? If so we will develop the settings menu in the near future and create a pull-request when it's finished. If not, what would you like to see different or what suggestions do you have?

[gkatsev]

Yeah, this is definitely something that we want to have given how many menu buttons we can have now. I commented on it back in march.
However it is done, I would like to get @OwenEdwards involved to make sure that it is fully accessible to both keyboard, mouse, and screen reader users.
If there's things that need to be changed in the other components to make making such a menu easier to build, assuming it is backwards compatible/additive, it can be changed. For example, a menu item can expose a title attribute which refers to itself; captions off's menu item title could be off.

I sort of understand how the settings menu would look in your proposal but have a hard time understanding how it acts. Would you happen to have a quick mock-up of how it looks/acts?
Also, I'm not certain it's doable, but I think it would be nice if we can ship an MVP and then keep adding to it instead of having a complete solution immediately.

[Fruitsapje]

We have created a simple mockup with a possible way of how it looks. In the image a normal select is used, however we think it's better te make it into a UL so the “options” can drop to the topside(or any other side)instead of going down by default.

One other solution we could use, is the way YouTube handels these kind of menus in the settings, where the sub menu appears with its options when it's pressed and the settings menu disappears.

The MVP in this case would be the settings menu consisting of only sub menus, where we later can add single buttons and/or sliders etc.

[gkatsev]

Talking about this with @dmlap, @heff, and @mmcc we were thinking that we don't really know what the best way to make this menu would be. If that is the menu that plugins and more items get added to, then we end up with a similar issue to what we currently have on the control bar: we'll end up with a settings menu that's two player heights tall because of a bunch of settings.
We were wondering if maybe what we should do is make this settings menu in a plugin -- something like videojs-dock -- so that we can more easily iterate on as we figure out a design. Once it's settled down a bit more we can pull it in -- videojs-dock should be pulled in as soon as someone (read: me) stops procrastinating and actually does it. There's probably stuff that needs to change in videojs, specifically around menus exposing the right information and that should definitely be changed in videojs as necessary.
What do you think @Fruitsapje?

[Fruitsapje]

This is fine by us, we will develop this as a plugin then for now. One question we have is wether you want us to make it on our own github and later move it to the videojs org / merge it or that we create a repo at the videojs org immediately?

[gkatsev]

I'm created a new repo videojs-settings-menu for this and added you as a collaborator.
Would be good if you can use plugin generator to scaffold it out.