Skip to content
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
wants to merge 3 commits into
base: master
Choose a base branch
from

Conversation

tytan652
Copy link
Contributor

@tytan652 tytan652 commented Mar 30, 2022

Summary

  • Switch main dock system to ADS
  • 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 for now.

Motivation and Context

  • Provide a better dock system to end-users.
  • I consider that I made enough progress on my WIP branches to make this RFC.
  • Also because I require feedback about the dock separation part.

My WIP branches:

Potential ideas suggestions completed by this RFC:

@RytoEX
Copy link
Member

RytoEX commented Mar 30, 2022

Wayland is not properly supported by Qt yet. If you use Wayland, then you should set the session type to x11: XDG_SESSION_TYPE=x11 ./AdvancedDockingSystemDemo. You will find more details about this in issue githubuser0xFFFF/Qt-Advanced-Docking-System#288.

@GeorgesStavracas ?

@tytan652
Copy link
Contributor Author

tytan652 commented Mar 30, 2022

Wayland is not properly supported by Qt yet. If you use Wayland, then you should set the session type to x11: XDG_SESSION_TYPE=x11 ./AdvancedDockingSystemDemo. You will find more details about this in issue githubuser0xFFFF/Qt-Advanced-Docking-System#288.

I want to precise this is the same for Qt Docking System, it's not properly supported either.

Edit note: I wish to avoid having to add a platform like OBS_NIX_PLATFORM_XWAYLAND because both docking system don't work properly under Wayland because Qt maybe don't care about that or consider it not a priority at all.

@tytan652 tytan652 force-pushed the advanced_docking branch 8 times, most recently from 10e2fb0 to e829764 Compare March 31, 2022 09:46
@GeorgesStavracas
Copy link
Member

Wayland is not properly supported by Qt yet. If you use Wayland, then you should set the session type to x11: XDG_SESSION_TYPE=x11 ./AdvancedDockingSystemDemo. You will find more details about this in issue githubuser0xFFFF/Qt-Advanced-Docking-System#288.

@GeorgesStavracas ?

I feel somewhat hopeless that we'll ever see good Wayland support for Qt. It's not only qt-wayland still has glaring bugs; the commercial nature of Qt means that if we contribute with bugfixes, they take way too long to be reviewed, and even when they're accepted, they're not backported. The Wayland backend is third-class on their priorities, the core of Qt is itself modelled against X11 and Windows APIs, and qt-wayland is merely an afterthought, often incompatible with the abstractions in place. In other words, qt-wayland seems to be there to check some boxes for customers, not to have actual Wayland support.

So yeah, I don't think we'll see proper docking using subsurfaces and the xdg-positioner protocol any time soon. And even if Qt magically gains such support, ADS would still need to be adapted, which would probably mean another year or more.

(Though, I must say, I'm a little skeptical about the entire docking concept. Docking leaks app-specific logic into the window management realm, and then we have problems with tiling, window ownership, modality, and basically break the app on anything that is not the traditional floating window model. But I digress.)

I'm not sure if the expectation is for me to fix that? If so, sorry, I have little motivation to contribute to qt-wayland upstream these days. I still have a bitter taste in my mouth for trying to fix that Wayland crash last year. 🙁

I wish to avoid having to add a platform like OBS_NIX_PLATFORM_XWAYLAND

There is no Xwayland platform at all :) There is either X11, or Wayland. If an app is running as X11, it should pick X11 code paths; if an app is running as a Wayland app, it should pick Wayland paths; there is no in-between there.

@tytan652
Copy link
Contributor Author

So yeah, I don't think we'll see proper docking using subsurfaces and the xdg-positioner protocol any time soon. And even if Qt magically gains such support, ADS would still need to be adapted, which would probably mean another year or more.

Just want to precise that ADS does not rely on Qt Docking System implementation. So if possible (I have no experience with Wayland development), a support of Wayland could be added to ADS.

@GeorgesStavracas
Copy link
Member

Just want to precise that ADS does not rely on Qt Docking System implementation. So if possible (I have no experience with Wayland development), a support of Wayland could be added to ADS.

That's correct, what I was trying to say is that both Qt's docking system and ADS rely on lower level interfacing with the windowing system, which in this case doesn't exist for qt-wayland.

@tytan652 tytan652 force-pushed the advanced_docking branch 5 times, most recently from 0e23698 to 917e59b Compare April 1, 2022 16:37
@tytan652 tytan652 marked this pull request as ready for review April 1, 2022 16:38
@tytan652 tytan652 force-pushed the advanced_docking branch 10 times, most recently from f758513 to 1f8a96a Compare April 2, 2022 17:27
@tytan652
Copy link
Contributor Author

tytan652 commented Jul 2, 2022

  • Updated transition widget
  • Added what could be done if the switch to ADS is done with the switch to Qt6
  • Rename every function with _adv_dock to _dock or _dock_2

@tytan652
Copy link
Contributor Author

tytan652 commented Jan 23, 2023

Put as draft to prioritize #53 over this.

@tytan652 tytan652 marked this pull request as draft January 23, 2023 21:59
@Warchamp7
Copy link
Member

Putting aside the Wayland issues, is there other comments or concerns here?

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 makers may ignore to theme this bar.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
Theme makers may ignore to theme this bar.
Theme authors won't be required to theme the titlebar.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The sentence is for showing that theme authors will ignore it because they don't develop the them to work on the Windows, macOS and Linux.

text/0047-switch-to-advanced-docking-system.md Outdated Show resolved Hide resolved
text/0047-switch-to-advanced-docking-system.md Outdated Show resolved Hide resolved
The state of those are saved through `"windowState"` global config.

## 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.
Copy link
Member

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?

Copy link
Contributor Author

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.

@tytan652
Copy link
Contributor Author

tytan652 commented Mar 31, 2024

Undraft to avoid the "it's a draft so no need to review for now" situation even if there is still some TODO.

@tytan652 tytan652 marked this pull request as ready for review March 31, 2024 11:16
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants