Add RFC: Redesign properties to suit small screens

[feetstv]

Summary

Redesign the properties window and view to suit smaller screens.

This proposal comes in three parts:

1. Make the OBSBasicProperties layout horizontal and fix the contained OBSPropertiesView width to 300px
2. Update the OBSPropertiesView layout so that widgets are smaller and laid out more space-efficiently to fit within the 300px

Motivation

It is, and always has been, my belief that OBSBasicProperties does not make efficient use of screen real estate, particularly on smaller displays. To my mind, this comes down to the vertical layout of the window. The issues are:

• to display the source preview at a reasonable size, the window must be fairly large or the splitter must be dragged down, thus showing few property widgets. This leaves laptop users with two choices:
  • small preview with a lot of property widgets
  • reasonable preview with few property widgets
• to display the source preview at a reasonable width, the window must be fairly wide. This elongates the property widgets — in most cases, they don't need to be that long

Examples

Links

• Read the full RFC
• In-progress branch

[tytan652]

Maybe it's because I'm tired (recently woke up) when I write those lines.

But I feel like OBSPropertiesView are considered in this RFC as something that is only used by source and filter which is wrong, Properties API is almost used by any object (struct) type provided by libobs (encoder, services, outputs…) even if not actually used, other RFCs are here to change that.

Edit: IIRC even the DeckLink UI use it.
Edit 2: I forgot, scripting use it too.

[feetstv]

Properties API is almost used by any object (struct) type provided by libobs

Yes, but I'm not modifying the properties API, just the view.

Properties API is used in lots of places, but OBSPropertiesView is only used by window-basic-properties (which includes the transitions window), window-basic-filters, window-basic-settings, AJAOutputUI, and DecklinkOutputUI.

I've already accommodated the fact that OBSPropertiesView is used in places other than the properties and filters with the wideLayout flag, which displays everything as it already is.

[tytan652]

OBSPropertiesView is for me bound to the Properties API, this is the type that interpret it.

Otherwise maybe it's just the wording "re-used" that lead me to that, but it just nitpicking at this level.

[feetstv]

Edit: IIRC even the DeckLink UI use it.
Edit 2: I forgot, scripting use it too.

And for that, my changes to OBSPropertiesView still supports the current layout.

[PatTheMav]

In general I'm very much in favour of using inspectors in sidebars for this as this is the pattern used by most pro apps (and most macOS applications for that matter) anyway (as explained in the RFC).

The constraints created by inspectors also encourage more thoughtful design of the UI elements themselves (and their layout) as well as authors to consider how to present the options (and how many).

Though this might also require adding support for "expendable" areas and probably the ability to add additional tabs (to avoid throwing an entire smorgasbord of options into a single pane).