Add RFC: Separate context bar code into UI and plugins

[norihiro]

Description

This RFC proposes to separate the implementation of the context bar into UI/ and plugins/.

Motivation and Context

UI has the implementation of the context-bar for each source type.
As the result, property names are hard-coded in both UI and plugins.
In possible future modification, it might require to change both plugin and UI, which might lead a potential bug.

It is a good implementation to separate the plugin-specific implementation from the UI.

This will also enable 3rd party plugins to have their context bar.

Rendered RFC

[gxalpha]

I like this approach! I thought of a similar concept (to the first variation of the two) a while back so was happy to see this RFC.
It might make sense to specify a number of items perhaps? So that only up to maybe 3 properties would get returned.

Additionally, this doesn't handle what happens to things that are currently custom crafted, like media controls. Sources like the media source currently indicate that they can be media controlled, should those just not implement this new API? What should happen if they both implement this but also can be controlled?

[norihiro]

It might make sense to specify a number of items perhaps? So that only up to maybe 3 properties would get returned.

The biggest number of items is 3 for the text source. Around 4 would be a maximum I think. Do we need to have a hard-coded maximum number or just recommended by the API document?

Type	Number of items	Comment
Browser	1	Refresh button
Color	1	Choose color button
Capture, etc.	2	Device selector, activate button
Game capture	2	Mode selector, window selector
Image	1	Path
Text	3	Font, color, text

Additionally, this doesn't handle what happens to things that are currently custom crafted, like media controls. Sources like the media source currently indicate that they can be media controlled, should those just not implement this new API? What should happen if they both implement this but also can be controlled?

I was not considering the media control. Media control toolbar (class MediaControls) and the context bar are exclusively shown so that it might be a good way to have the media control toolbar in the same API.

The media control toolbar implements some buttons, sliders to indicate and control playing time, and text label indicating slideshow page.

To have the buttons from obs_properties_t, we need to have an API like obs_property_button_set_icon.
The API may set themeID such as playIcon and nextIcon so that the actual icons follow the current theme.
Or, libobs may provide enumeration listing all icon types.

I need more consideration for the slider and the page label. We might add a new variation of obs_properties_add_int_slider but I'm afraid it is not a good idea to change the settings data for current playing time every second.

[norihiro]

So far, I don't have a concrete idea to implement the media control UI into the property context bar.

The slider is the biggest problem. The slider gets updated every second. The slider is not associated with any object in the settings.

The slider displays and controls the current duration. However, every property type, except the button, is tied to an object in the settings. This is outside of the architecture made by obs_properties_t and obs_data_t.

If adding a new property type that displays the internal state which is not included in the settings, I also want to consider the graphical display of the compressor, expander, and gate filters.

I think the rewrite of the context toolbar won't make it more difficult to rewrite the media control. So, we can just rewrite the context toolbar at first.