Avoid having two docks with the same object name

[tytan652]

Description

Depends on:

• Refactor main docks toggle and integration and browser docks #7636

Dependency of:

• Add browser dock functions in the frontend api #7638

https://doc.qt.io/qt-6/qmainwindow.html#saveState

You should make sure that this property is unique for each QToolBar and QDockWidget you add to the QMainWindow.

We should avoid letting plugins add docks with the same object name. So to implement that:

• obs_frontend_add_dock() is deprecated in favor of obs_frontend_add_dock_by_id() and obs_frontend_add_custom_qdock() which ask for an unique id (object name). The dock is not added if the id is already used and return false in this case.
• Also the new method does not return a QAction since internally we use the one included in QDockWidget.
• obs_frontend_add_dock() implements a temporary workaround to avoid this.
• obs_frontend_add_custom_qdock() replace the usage of obs_frontend_add_dock() where the returned QAction is deleted (e.g. Sources Dock plugin). The dock is not added if the id is already used and return false in this case.
• If the object name of docks added with obs_frontend_add_dock() and obs_frontend_add_custom_qdock() happen to be changed, the object name is changed back to its original.
• Docks added with new methods can be removed from the UI with obs_frontend_remove_dock()

Note: If obs_frontend_add_custom_qdock() usecase is something we want to avoid, review the code about removing it and deprecate the usecase through obs_frontend_add_dock() deprecation.

Motivation and Context

Fix a potential issue and preparation for PRs that depends on this one.

Also make the API more neutral toward the used dock system for non-custom methods.

How Has This Been Tested?

• Modified Downstream Keyer plugin to use obs_frontend_add_dock_by_id() or obs_frontend_add_custom_qdock()

Types of changes

• New feature (non-breaking change which adds 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.

[PatTheMav]

Personally I'd prefer to avoid the whole "function_call[insert integer here]" shenanigans, it always seems half-arsed to me. If code uses the old signature it should break and throw a compile-time error, forcing any authors relying on it to update to the new API, especially as this probably won't end up in a minor version update anyway.

Otherwise we're dragging a whole ecosystem of mixed implementations with us until we end up with obs_frontend_add_dock5.

[tytan652]

Then how should I name it rather than adding a 2, because the old function is deprecated because the custom QAction is no longer created and and the new one require an id.

Edit: C does not support having two function named the same even with different parameters and return type.

[PatTheMav]

Is there other code that uses this function? Because if it is only us, then we should fix all invocations of the code, but I'm afraid you might tell me that plugins are allowed to use this function?

[tytan652]

If you are talking about obs_frontend_add_dock(), it's a Frontend API function used by many plugins.

[PatTheMav]

I was afraid you'd say that - internal UI methods shouldn't be exposed as-is to the API, but that's for later to fix.

I'd suggest naming the function obs_frontend_add_dock_by_id then, because it's a) different and b) clearly communicates what it does.

[tytan652]

Renamed obs_frontend_add_custom_dock to obs_frontend_add_custom_qdock.

[tytan652]

Replace QUuid usage in obs_frontend_add_dock by os_generate_uuid.

[tytan652]

Added this note to the PR description:

Note: If obs_frontend_add_custom_qdock() usecase is something we want to avoid, review the code about removing it and deprecate the usecase through obs_frontend_add_dock() deprecation.