-
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
base: master
Are you sure you want to change the base?
Conversation
|
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 |
10e2fb0
to
e829764
Compare
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. 🙁
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. |
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. |
0e23698
to
917e59b
Compare
f758513
to
1f8a96a
Compare
f0d82af
to
9ae8048
Compare
9ae8048
to
0858f88
Compare
0858f88
to
5d939e3
Compare
|
8cf55f3
to
e62b2cc
Compare
10fbb32
to
363fa83
Compare
|
Putting aside the Wayland issues, is there other comments or concerns here? |
363fa83
to
2d4f5da
Compare
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. |
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.
Theme makers may ignore to theme this bar. | |
Theme authors won't be required to theme the titlebar. |
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.
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.
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. |
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.
Undraft to avoid the "it's a draft so no need to review for now" situation even if there is still some TODO. |
Summary
Note: The "central widget" design is kept for now.
Motivation and Context
My WIP branches:
Potential ideas suggestions completed by this RFC: