frontend: Update transform dialog

[Warchamp7]

Description

Adds a new AlignmentSelector widget that returns both Qt::alignment values and a currentIndex corresponding to an alignment position.

Updates the appearance and functionality of the Transform dialog

• Visual changes
• Layout changes
• Renames the bounds type values to more user-friendly terms
• Adjusts behaviour of a few actions to improve UX
  • Changing position alignment will update X/Y position so the source doesn't shift visually
  • Changing bounds type off BOUNDS_NONE applies the size to the bounding box and resets the scaling size
  • Changing bounds type to BOUNDS_NONE adjusts position and size so the source doesn't shift visually

Note

Positioning is incorrect when switching back to BOUNDS_NONE while using a bounds type with crop to bounds enabled. This will be fixable later with the additional libobs function added in #12383 but is not any worse than the current behaviour.

Motivation and Context

Want to bring this dialog in line visually with other recent UI changes and do a pass on it's behaviour.

How Has This Been Tested?

Lots of resizing and position/alignment changes to various sources.

Types of changes

Checklist:

• My code has been run through clang-format.
• I have read the contributing document.
• My code is not on the master branch.
• The code has been tested.
• All commit messages are properly formatted and commits squashed where appropriate.
• I have included updates to all appropriate documentation.

[Warchamp7]

Updated with QAccessibleInterface for the new widget to better support screen readers and other accessibility tools.

[PatTheMav]

I tested this specifically with keyboard navigation enabled from macOS' accessibility features and noticed that both alignment controls are only available after tabbing through the entire window's contents (including the close button) and I had to press tab 5 more times to get from the first box to the second and from the second box back to the first drop down.

From an A11Y point of view I think those boxes should be accessible right after their associated controls (just like they are visually aligned with them). I haven't had the time to check where those 5 additional controls came from that I had to "tab through".

[Warchamp7]

I tested this specifically with keyboard navigation enabled from macOS' accessibility features and noticed that both alignment controls are only available after tabbing through the entire window's contents (including the close button) and I had to press tab 5 more times to get from the first box to the second and from the second box back to the first drop down.

From an A11Y point of view I think those boxes should be accessible right after their associated controls (just like they are visually aligned with them). I haven't had the time to check where those 5 additional controls came from that I had to "tab through".

Those controls should be in logical order of the window, and they are for me on Windows. Very odd that it isn't the case on mac?

[PatTheMav]

Those controls should be in logical order of the window, and they are for me on Windows. Very odd that it isn't the case on mac?

Tested this again with the current state of the PR today and the new controls are now correctly navigated to after their corresponding spin boxes when tabbing through the window.

The only remaining quirks I found are:

• The dropdown for bounding box mode is ignored for tab-navigation
• When my focus is on any other control (e.g. the "Crop Left" spin box) and I then change the bounds dropdown from "Automatic" to "Fit", then the "W" spinbox gets the "in focus" style (dark background, blue border) but is not actually focused. It seems like that happens because the entry for "Fit" in the dropdown is just over the "W" spinbox. This might be related to our use of native dropdown on macOS.

The second quirk applies to all Qt widgets - if I move the mouse further to the right in the dropdown so my mouse cursor happens to be above the "Crop Bounds" checkbox, then that one is rendered with the the "hover" state style and keeps it until a full window state update.

---

On another note I stumbled over use of "W" and "H" while playing with the bounds inputs and it felt a bit "wrong" that we use "Left", "Top", etc. but not "Width" and "Height". "X" and "Y" are not abbreviations but the literal names of the axes, so those feel more "right" in their shortened form.

[Warchamp7]

• The dropdown for bounding box mode is ignored for tab-navigation

I'm unable to replicate this. I do think the bounding box alignment widget was in the wrong order though, so that should be fixed after my next force push.

• When my focus is on any other control (e.g. the "Crop Left" spin box) and I then change the bounds dropdown from "Automatic" to "Fit", then the "W" spinbox gets the "in focus" style (dark background, blue border) but is not actually focused. It seems like that happens because the entry for "Fit" in the dropdown is just over the "W" spinbox. This might be related to our use of native dropdown on macOS.

The second quirk applies to all Qt widgets - if I move the mouse further to the right in the dropdown so my mouse cursor happens to be above the "Crop Bounds" checkbox, then that one is rendered with the the "hover" state style and keeps it until a full window state update.

I do believe this is a quirk of macOS native dropdowns. I think an easy way to test would be to try the ComboBox in the transitions dock which has the duration lineedit and buttons below it. Can you reproduce there?

obs64_MYvvn1aH1t.mp4

Reverted W/H back to full names as I agree with the feedback.

[PatTheMav]

I'm unable to replicate this. I do think the bounding box alignment widget was in the wrong order though, so that should be fixed after my next force push.

Still happens here: When I use to navigate through the items, it skips from the position alignment widget to the bounds alignment widget. This might also be related to native drop down usage.

I do believe this is a quirk of macOS native dropdowns. I think an easy way to test would be to try the ComboBox in the transitions dock which has the duration lineedit and buttons below it. Can you reproduce there?

Yep, though requires a bit more work as another widget needs to have input focus. Was able to reproduce this by having an active input for a scene item name and selecting a transition that was placed over the duration input field in the native drop-down.

I agree that this will be due to the interplay between the native interface element and Qt's "internal" widgetry though.

[RytoEX]

Nit on container/QFrame naming.