-
Notifications
You must be signed in to change notification settings - Fork 48
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add RFC: Switch to Advanced Docking System #47
Open
tytan652
wants to merge
3
commits into
obsproject:master
Choose a base branch
from
tytan652:advanced_docking
base: master
Could not load branches
Branch not found: {{ refName }}
Loading
Could not load tags
Nothing to show
Loading
Are you sure you want to change the base?
Some commits from the old base branch may be removed from the timeline,
and old review comments may become outdated.
Open
Changes from all commits
Commits
Show all changes
3 commits
Select commit
Hold shift + click to select a range
File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,281 @@ | ||
# Summary | ||
|
||
- Switch main dock system to [ADS][1] | ||
- Make ADS dock state per profile | ||
- Allow the user to switch between pre-made layouts | ||
- Plugins could register their own | ||
- Users could save their own | ||
- Dock added by plugins with the old methods are added as "*Legacy dock*" | ||
|
||
Note: The "central widget" design is kept. | ||
|
||
# Motivation | ||
|
||
Provide a better dock system to end-users. | ||
|
||
# Design | ||
**DISCLAIMER**: The "central widget" design is kept, switching to a non-"central widget" one is not part of this RFC. | ||
|
||
## Main window dock separation | ||
To make OBS Studio compatible with ADS, Controls, Transitions, Mixer, Sources, Scenes docks need to be separated from the main window. | ||
|
||
And the central widget of main window should also be separated as well to become the central dock. | ||
|
||
So the docks will be separated as widget class with their own UI class. | ||
|
||
Then those widget are inserted in OBSDock (QDockWidget) and the central widget and put as main window central widget. | ||
|
||
And then we switch to ADS, all those widget will become docks and added to the ADS dock manager. | ||
|
||
The OBSBasic heavily rely on some UI element from those docks, to resolve that the related code will be refactored to remove this dependance going toward a MVC pattern. | ||
|
||
Each widget class will be put as a friend class in OBSBasic to allow access to private slot and avoid moving them as public. | ||
|
||
### Controls widget | ||
*Future ADS Controls dock widget* | ||
|
||
All the buttons of this dock will be connected through signal and slots to OBSBasic. | ||
|
||
Some hotkeys and pause functions rely on UI buttons, so OBS Basic will be refactored to remove this dependance. | ||
|
||
### Transistions widget | ||
*Future ADS Transitions dock widget* | ||
|
||
Transitions will be stored in OBSBasic and selected through the combo box of the widget. | ||
|
||
The transition duration will become an attribute of OBSBasic, and signal and slots will be setup to synchromise it with the dock spinbox. | ||
|
||
Buttons for adding, removing and open settings will be connected through signals and slots to OBSBasic. | ||
|
||
### Mixer widget | ||
*Future ADS Mixer dock widget* | ||
|
||
The base dock is easily separable, but the VolControl class can be refactored (toward MVC) later because this is not a requirement for this RFC. | ||
|
||
### Sources widget | ||
*Future ADS Sources dock widget* | ||
|
||
OBSBasic heavily rely on the SourceTree from the widget, but a refactoring will not be considered as a requirement for this RFC. So the class of the sources widget will have OBSBasic as a friend class. | ||
|
||
### Scenes widget | ||
*Future ADS Scenes dock widget* | ||
|
||
OBSBasic heavily rely on the SceneTree from the widget, but a refactoring will not be considered as a requirement for this RFC. So the class of the scenes widget will have OBSBasic as a friend class. | ||
|
||
### Central widget | ||
*Future ADS Central dock widget* | ||
|
||
Some context bar, preview/program and nudge related code is moved to the central widget class. | ||
|
||
This class will have OBSBasicPreview as a friend class. | ||
|
||
This class will be a friend class of OBSBasic also to have access to some gs_vertbuffer_t type attributes. | ||
|
||
## ADS | ||
The Advanced Docking System, require to add a Dock Manager in the main window and then add the central widget and then add other docks. | ||
|
||
Some work on themes CSS will be required. | ||
|
||
### About obs-deps | ||
|
||
obs-deps already build Qt for macOS and Windows, so adding a ADS script to the Qt tarballs is not a problem. | ||
|
||
### Floating docks titlebar on X11 | ||
On X11, ADS provide two type of titlebar for floating docks: | ||
|
||
- Native | ||
|
||
[![Native titlebar under GNOME](./0047-switch-to-advanced-docking-system/linux_native_floating_dock_titlebar.png)]() | ||
|
||
- QWidget based (WIP CSS) | ||
|
||
[![QWidget titlebar](./0047-switch-to-advanced-docking-system/linux_qwidget_floating_dock_titlebar.png)]() | ||
|
||
The QWidget one is used by default when using KWin based Desktop Environement like Plasma. And this titlebar requires some CSS in the themes to match it. | ||
|
||
So the QWidget based titlebar usage will be enforced thanks to a flag for the Dock Manager to "unify" experience between desktop environement. | ||
Theme authors may ignore to theme this bar. | ||
|
||
### Dock state | ||
*The per profile dock state feature is not taken into account to describe those changes.* | ||
|
||
In the global config (`global.ini`). | ||
- `"dockState"` is kept for for backward compatiblity and no longer overwritten. It will be used if the following state is not present. | ||
- `"windowState"` is the state of the main window which also contains legacy docks state. | ||
- `"advDockState"` is the state of the dock manager which contain only the states of any ADS dock. | ||
|
||
Service integrations only save `"advDockState"` | ||
|
||
ADS dock state is compressed by default but behind the scene it's XML. | ||
|
||
### OBSAdvDock | ||
OBSAdvDock is a class which inherit `ads::CDockWidget` class. | ||
|
||
This class has a constructor which require a QWidget and setup some things arround the widget and set some connections. | ||
|
||
It adds a warning message when closing a dock from a close dock button. | ||
|
||
It allows to reset a dock position after a UI reset or a layout change with a possibility to reset the size if set beforehand. | ||
|
||
### Custom Browser docks and BrowserAdvDock | ||
The custom browser docks feature is modified to use BrowserAdvDock which inherit OBSAdvDock. | ||
|
||
Those docks are stored in the dock manager and their names is stored in a QStringList for browser docks to be able to get the dock from the manager to modify it like changing the URL. | ||
|
||
Each of those browser dock is named `extraBrowser_$UUID` where `$UUID` is replaced by the dock UUID to have a really unique name. | ||
|
||
### Service integration docks | ||
|
||
Like custom browser docks, those integration are modified to use BrowserAdvDock. But their names is stored in the QStringList for plugins extra docks. | ||
|
||
Those docks are named `obs-$SERVICE_$DOCK_NAME` where `$SERVICE` is the service name in lowercase and `$DOCK_NAME` the name of the dock. | ||
|
||
`"dockState"` will be imported from the integration config if `"windowState"` is not present. | ||
|
||
### Reset UI action | ||
1. Legacy dock are hidden | ||
2. The default state written in XML is applied | ||
3. Each not shown OBSAdvDock/BrowserAdvDock dock have its position and size reseted. | ||
|
||
## Legacy dock | ||
|
||
If the deprecated frontend API method `obs_frontend_add_dock()` is used the dock added through this method are added to a sub-menu named `Legacy dock` of the Dock menu. | ||
|
||
[![Legacy dock menu](./0047-switch-to-advanced-docking-system/legacy_dock.png)]() | ||
|
||
When openning a legacy dock, a message will appear explaining that those docks will not meld wery well with ADS docks. | ||
|
||
The state of those are saved through `"windowState"` global config. | ||
|
||
`obs_frontend` | ||
|
||
### About custom QDockWidget | ||
|
||
Docks added through `obs_frontend_add_custom_qdock()` (or `obs_frontend_add_dock()` with the returned QAction deleted)will have almost the same treatment as legacy docks because by design those don't have a QAction in the dock menu. | ||
|
||
## Per profile dock state | ||
Move the `"advDockState"` from global config to the profile and integration no longer store their own state. `"windowState"` is kept global. | ||
|
||
If a release happen between the switch to ADS and this feature, import the one from the integration service if the profile has one set up. | ||
|
||
## Layouts management | ||
Add the feature, to switch between registered/saved dock layouts: | ||
- Though a sub-menu in the dock menu | ||
- Through the frontend API | ||
- Can be extended later to be through a hotkey | ||
|
||
OBS Studio could provide layouts, the default count as one. | ||
|
||
Plugins could also register their own XML layouts through the frontend API. | ||
|
||
Users could be able to save their own layouts. Those layouts will have their name prefixed with`user_` to avoid name conflicts. | ||
|
||
Note: ADS perspective feature is not directly used because it relies heavily on QSettings. | ||
**TODO: Check if ADS perpective has changed, or maybe upstream improvement to it** | ||
|
||
## Frontend API | ||
|
||
`obs_frontend_add_dock_by_id()` implementation is to be modified to use OBSAdvDock rather than OBSDock. | ||
|
||
Default height and width would need to be based on the widget size when added as a dock. | ||
|
||
`obs_frontend_remove_dock()` stay the function to remove the dock. | ||
|
||
### Add a dock layouts | ||
|
||
**TODO: Refactor API design** | ||
|
||
```c++ | ||
#define obs_frontend_add_dock_layout(title, unique_name, xml_layout) \ | ||
obs_frontend_add_module_dock_layout(obs_current_module(), \ | ||
title, unique_name, xml_layout) | ||
EXPORT void obs_frontend_add_module_dock_layout(obs_module_t *module, | ||
const char *title, | ||
const char *unique_name, | ||
const char *xml_layout); | ||
``` | ||
|
||
This allow the plugin to add a dock layouts in XML to the UI. ADS allow to test a layout (state/perspective) without applying it, so the layout will be tested before registering it. | ||
|
||
### Get a list of docks layouts | ||
```c++ | ||
EXPORT char **obs_frontend_get_dock_layouts(void); | ||
``` | ||
|
||
This allow the plugin to get a list of registered dock layouts from the UI. | ||
|
||
### Set a registered dock layout | ||
```c++ | ||
EXPORT void obs_frontend_set_dock_layouts(const char *layout_name); | ||
``` | ||
|
||
This allow the plugin to set a registered dock layouts to the UI, the asked name should come directly from the get list method. | ||
|
||
### Remove a dock layouts | ||
|
||
**TODO: Refactor API design** | ||
|
||
```c++ | ||
#define obs_frontend_remove_dock_layout(unique_name) \ | ||
obs_frontend_remove_module_dock_layout(obs_current_module(), \ | ||
unique_name) | ||
EXPORT void obs_frontend_remove_module_dock_layout(obs_module_t *module, | ||
const char *unique_name); | ||
``` | ||
|
||
This allow the plugin to remove a dock layouts from the UI. | ||
|
||
### About custom dock | ||
|
||
Switching to ADS would force to deprecate this "feature", plugins authors will have to use only `obs_frontend_add_dock_by_id()`. | ||
|
||
- ADS will be built as a static library on most of the platforms and so plugins authors will be unable to use it's API. | ||
- `obs_frontend_add_custom_qdock()` was a temporary measure until a change of docking system could allow the behavior to be truly deprecated. | ||
- Custom docks were mainly used to avoid over-filling the docks menu which would create a long list (e.g. [Sources Dock][6]). | ||
|
||
### Get the XML behind a registered dock layout | ||
*Method meant to allow a Dock Layout editor tool to exist* | ||
|
||
```c++ | ||
EXPORT char *obs_frontend_get_dock_layout(const char *layout_name); | ||
``` | ||
|
||
This allow the plugin to get a registered dock layouts XML, the asked name should come directly from the get list method. | ||
|
||
### Get the XML of the actual dock state | ||
*Method meant to allow a Dock Layout editor tool to exist* | ||
|
||
```c++ | ||
EXPORT char *obs_frontend_get_current_dock_state(void); | ||
``` | ||
|
||
This allow the plugin to get the dock states XML of the UI. | ||
|
||
### Events addition | ||
- An event before the startup restore dock state and `OBS_FRONTEND_EVENT_FINISHED_LOADING` to allow plugins to load their docks before the restore or redo a restore if the number of extra docks has changed. This event could possibly be emitted when profile is changed before restoring profile dock state and `OBS_FRONTEND_EVENT_PROFILE_CHANGED`. | ||
|
||
- An event when the a dock layout is applied (reset or not) to allow plugins to reset the positions of their customs docks, if they want to. | ||
|
||
## About making dock states future proof | ||
By default generated state are version 0. If one day we make a breaking change like remove the notion of central widget and so change the version. | ||
|
||
We could take the saved `"advDockState"` and uncompress to edit the XML, to make it compatible with the change. | ||
|
||
# Drawbacks | ||
We can't convert old `"dockState"` to the new dock system. | ||
|
||
# Additional Information | ||
About Wayland support, Qt and ADS docking system have very bad support because of Qt Wayland. The Wayland backend is apparently third-class on Qt's priorities. | ||
|
||
My WIP branches: | ||
- [Dock separation][2] | ||
- [Central widget separation][8] | ||
- [Switch to ADS][3] | ||
- [Frontend API to add ADS dock][4] | ||
|
||
[1]: https://github.com/githubuser0xFFFF/Qt-Advanced-Docking-System | ||
[2]: https://github.com/tytan652/obs-studio/tree/dock_separation | ||
[3]: https://github.com/tytan652/obs-studio/tree/advanced_docking | ||
[4]: https://github.com/tytan652/obs-studio/tree/ads_frontend_api | ||
[6]: https://obsproject.com/forum/resources/source-dock.1317/ | ||
[8]: https://github.com/tytan652/obs-studio/tree/central_widget_separation |
Loading
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
Binary file added
BIN
+9.24 KB
.../0047-switch-to-advanced-docking-system/linux_native_floating_dock_titlebar.png
Loading
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
Binary file added
BIN
+9.02 KB
...0047-switch-to-advanced-docking-system/linux_qwidget_floating_dock_titlebar.png
Loading
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I do worry slightly about dock layouts being tied to profiles, as I expect most users won't have a different layout for each profile. Do we maybe want to have a global one by default, and if a user creates a layout then tie it to the current profile by default?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Unfortunately, this is also disambiguate the service integration that already does that into a more service-agnostic approach.
It's not only profiles with integration enabled, it's every profiles.