Properties window layout

[feetstv]

Hello, OBS friends.

I would like to propose a change to the venerable Properties window for sources. It is, and always has been, my belief that the Properties window 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

Proposal

This proposal comes in two parts:

1. Make the Properties window layout horizontal and fix the Properties view width to 300px
2. Update the Properties view layout so that widgets are smaller and laid out more space-efficiently

Make the Properties window layout horizontal

The motivation here is to make better use of the window's real estate.

At a given sensible, preview at the left and Properties view at the right, there should be more property widgets be visible than in the current layout.

Also, the Properties view should be fixed in width to around 300px (subject to testing). This means:

• the layout is easier to use than using a splitter whilst solving the issue that the splitter was intended to resolve
  • the size of the preview is contingent on the window size, not window size and splitter
• this design lends the Properties view to being repurposable as a dock in future

Update the Properties view layout

To accommodate the Properties view being located on the side within a fixed width view, properties view widgets should be made smaller. The most straight-forward way to do this is to use a smaller font size.

Currently, the Properties view uses a QFormLayout to manage all of the widgets. This makes all labels for each widget the same width as the longest label. This is an incredibly wasteful use of horizontal screen real estate:

• if only one label is very long, every label becomes long, wasting horizontal space
• in the current vertical layout, some labels require the Properties window to be very wide in order to accommodate both the label and the widget
• in the horizontal layout, the Properties view would be so wide as to defeat the purpose of the change

Instead of using a QFormLayout, I propose a QVBoxLayout. This would change the layout from:

     Label: [     Widget     ]
Long label: [     Widget     ]

to

Label:
[     Widget     ]
Long label:
[     Widget     ]

Some widgets could further be adapted. For example:

• buttons with consistent text (Pick Color, Open File, etc.) could be reduced to a button with a glyph
  • these smaller buttons could be placed in-line with the label.
• superfluous or unnecessary labels could be reworded, restyled, or removed
• the Pick Color button in particular could be changed to simulate a color well (such as on web browsers with the <input type='color'> tag or macOS' NSColorWell control)

For example, the color picker could be changed so that:

1. the color code label is removed
2. the Pick Color button's text is removed
3. the Pick Color button's background color is changed to match the selected color

Color #1:
[     #ffffff     ] [Pick Color]

to the more space-saving

Color #1:    [   ]

Example

The result of such changes are the following:

Video capture source

Image source

Media source

Display capture source

Text source

Note the color well-like buttons.

Browser source

Browser source (small window)

Prior art

Narrow properties views, also called inspectors, are not uncommon. Apple (in its pro and productivity apps) and Adobe make good use of them, most software development IDEs have some kind of inspector layout.

Conclusion

As you can see, I have been working on code to achieve this. I need to clean it up before I make a PR. But before I do, I wanted to ask for comments or suggestions on how this could be improved.

Origin of the proposal

@gxalpha was working on a Properties Dock, I forked it and made similar changes to what I describe below. However, I realised that there would always be a mismatch between my version of the Properties Dock with its dock-optimised layout and the regular Properties window.

I believe that what I am proposing would benefit both the current workflow using a non-modal window and any future version of a Properties Dock which would benefit from being optimised for the narrow layout.

[WizardCM]

I haven't read your whole proposal yet, but I wanted to mention - Filters show the lists of filters on a sidebar on the left. Would it feel weird having that on the left and this on the right?

[feetstv]

This proposal is just for the Properties Window, not for Filters. I haven't quite figured that window out yet — perhaps filters list between the preview and the Properties view? Not sure.

I purposefully didn't mention it to keep the scope as focused as possible.

[tytan652]

Note that encoder in advanced mode also use the properties API (what is used to show those properties).

Edit: but we can just add a boolean to trigger the "newline" after the name of the option.

[WizardCM]

Sure, I mean more that if we were to make this change in a vacuum, users would be taught properties on the right, lists on the left. Is that a direction we want to persist?

Additionally, we would like to consolidate (at some stage) Properties and Filters into one window.

I do agree Filters is a tricky one due to the additional UI.

[feetstv]

Note that encoder in advanced mode also use the properties API (what is used to show those properties).

Yes, and there's a couple of hiccups with that. I haven't shown the screenshots of what that looks like yet because it's early days from a technical standpoint. I really only made this for me alone; I got encouragement to put up the discussion from another contributor.

I do agree Filters is a tricky one due to the additional UI.

That would be the ideal, possibly with tabs at the top to switch between Properties and Filters. Perhaps filter properties could be contained within some kind of accordion of collapsible sections, but I don't know what widget would be used for that in Qt.

Motion has the tab bars, Final Cut and Adobe's suite of apps have the collapsible sections.

[feetstv]

Edit: but we can just add a boolean to trigger the "newline" after the name of the option

Yeah, I did something like that. The result is new style and old style co-existing peacefully.

[feetstv]

I should point out, I'm aware of the massive spacing between the lines in the Properties view. Ironic of me to try to address screen real estate waste with … screen real estate waste! Obviously, that needs fixing, but you still get the general idea of the layout.

Ideally, the label for the widget would be closer.

[Fenrirthviti]

Is there a reason this was not submitted as an RFC? I understand that the RFCs have historically languished, but pushing further away from them is not something I would like to encourage at this time.

[feetstv]

I'm happy to submit as an RFC. Is there anything missing from this proposal that needs to be included in an RFC? If not, I can easily enough copy-paste the first post into an RFC.

[Fenrirthviti]

Nothing missing that I can see, I did just scan over it though. You'll want to use the RFC template, but I'm pretty sure the post covers all of those talking points already. Sorry for the hassle!

[feetstv]

Now posted as an RFC.

[Fenrirthviti]

Locking this as all further discussion should happen on the RFC linked above. Thanks for submitting!