frontend: Transitions (dock) separation part 1

[tytan652]

Description

Began to split transitions and transition duration storage from the UI.
Also makes the frontend code rely more on transitions UUID even if those are not preserved between sessions for now.

While this PR remove any kind of reliance on index of a transition, it does not overhaul things to rely only on UUID so there is still reliance on the transition name as an identifier. Same for retaining which transition was inserted last.

Motivation and Context

After multiple tries, I finally managed to separated the transitions data from this combobox, now it needs reviews and testings…

The awaited sequel of #7278, but it's the prequel of the expected sequel.

How Has This Been Tested?

Please tests

Types of changes

• Tweak (non-breaking change to improve existing functionality)

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.

[tytan652]

@PatTheMav, please just say to avoid mutator even if we check if present beforehand.

Using diffs for every mutator use make the review less readable and uses too much space that github ends up hiding stuff.

[PatTheMav]

@PatTheMav, please just say to avoid mutator even if we check if present beforehand.

Using diffs for every mutator use make the review less readable and uses too much space that github ends up hiding stuff.

I disagree, it is the correct tool for the job to highlight requested changes exactly where they are requested, including the context of the change. Expanding all changes takes a single click and that's a small price to pay for the improved clarity of changes and keeping discussions local to specific changes.

[tytan652]

I think you are mixing up the code selected and the diff that you explicitly type in the review. I'm talking about the second.

[PatTheMav]

I think all my comments were addressed, right?

[tytan652]

I think all my comments were addressed, right?

The conversation(s) I did not mark as resolved by myself were waiting for your feedback that if the changes to solve it were good for you.

[tytan652]

Just a rebase, I still did not found the source of my issues with the signal handler mutex and websocket…

[Warchamp7]

As noted by tytan above, this currently crashes when run. I'm putting a review to block merging as an extra safety.

[tytan652]

The issue at startup should be now resolved.

[PatTheMav]

I just tested this locally and for some reason the button to delete a transition is always disabled, even for transitions past the default "Cut" and "Fade" ones.

After relaunching OBS, the button to reach the transition properties or to rename it also became disabled for all of them.

[tytan652]

I feel dumb to not have caught that I forgot to "set transition" while setting the current transition.

Edit: I will squash the two last commit ("reduce" and "set the transition" with "replace combobox direct access") once everything is good.

[PatTheMav]

I'm afraid this still doesn't work right, as deleted transitions are retained in the dropdown:

• Given transitions A,B,C,D, and E
• Deleting E retains E in the list
• Deleting D retains D in the list
• Trying to delete D or E again asks for confirmation to delete C

Indeed the rename and properties actions also are associated with transition C, even when the retained transition D or E are selected.

[RytoEX]

I'm afraid this still doesn't work right, as deleted transitions are retained in the dropdown:

Has this changed since then?

[tytan652]

Yes, it was fixed

The crash was reportedly fixed.