-
Notifications
You must be signed in to change notification settings - Fork 170
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
No drop-shadow for Qt windows #437
Comments
TL;DR: This is a Qt issue, not a wayfire issue. This has little or nothing to do with wayfire. Wayfire already supports xdg-decoration protocol. This means clients are free to draw their own decorations or tell the compositor it wont render decorations and have the compositor draw them. Either way, I don't think you get shadows currently but you can create your own decoration plugin (or modify the existing one) to draw what you want. I do not know if Qt supports this protocol or offers a way for users to use it. The other option is to change the Qt decoration decoration code, the result of which you are seeing currently. EDIT: I have found you can use |
Thanks for the explanation! I was thinking about supporting Wayfire in LXQt at some point -- alongside KWin -- but, apparently, it's too soon. |
@tsujan Wait, is this working under KWin in Wayland? |
If you mean drop-shadow and customizable window decoration, yes. KWin-Wayland also supports the desktop cube and blur effect. I installed Wayfire only yesterday and was surprised by its high quality -- especially its nice effects. Will update it once in a while. |
I wonder how they get these shadows. Do they have a custom protocol? The applications from your screenshot seem to have client-side decorations, and generally clients with client-side decorations are responsible for shadows, for example Gedit, Nautilus, Chrome. |
For now, my knowledge of Wayland is minimal -- I just use/try it -- but I understand your reasoning. Unfortunately, I have no idea how they do it. It seems Qt's world is somehow different from GTK's, regarding Wayland. Hopefully, that won't be the case in future. |
Oh, as for Qt, I know it. Qt doesn't have CSD. |
Sorry to say it, but that's plain wrong. The screenshot you provided shows decorations which are not drawn by Wayfire. Wayfire's decorations look differently. |
Anyway, it seems like Qt must have some custom protocol to enable/disable these shadows. This will not be implemented in Wayfire's core, if there is somebody interested they should implement it as a plugin. |
I code in Qt :) I also know |
And I have written the Wayfire decoration code, and I am 100% sure these decorations are not drawn by Wayfire. I expect that Qt behaves differently, since the configurable default in Wayfire is to request the application to draw CSD instead of SSD (which might be the default in Kwin) |
I agree with you on that. But Qt doesn't draw them either. |
Who does that then? I have seen these decorations on VLC and Calibre as well. Maybe there is a common Qt-based library. |
Oh and by the way, if you want shadows for CSD, the best way is to ping the responsible people to implement that in the clients (even though it can be implemented as a plugin in wayfire). |
I have no idea. I know Qt but not Wayland. BTW, KDE devs seem to be against CSD altogether.
No CSD in Qt ;) |
I find that hard to believe since all Qt apps have the same decorations in Wayfire (and these are different from Xwayland and GTK decorations). Anyway the point is moot, Wayfire shouldn't need to do anything special, it is a client bug. |
https://blog.martin-graesslin.com/blog/2018/01/server-side-decorations-and-wayland/ Please note that I'm not a KDE developer. The above link doesn't mean I agree/disagree with anything. |
@tsujan I think you might be misunderstanding what @ammen99 is trying to tell you. The way the code works is that a client renders a buffer for its surface and gives it to wayfire. Wayfire doesn't know or care what the buffer contents are, it just puts it on the screen and respects the input region which is also given by the client. Since this buffer clearly contains decorations which are part of the client surface contents, this means client-side-decorations are being used. Period. It does not matter what code actually draws the decorations in this case; this code is being executed ultimately by the client. Basically, your screenshot shows decorations which are not drawn by wayfire, because wayfire doesn't draw decorations that appear this way. The other fact is that when using QtWayland native (with QT_QPA_PLATFORM=wayland set), the default is client-side-decorations. Qt absolutely does CSD, for its wayland application. |
I accept what you say about Wayfire and Wayland. What I'm sure about is that Qt's wayland codes have no relation to If so, KWin-Wayland forgets about the ugly/non-native wayland CSD of Qt and uses SSD. Wayfire doesn't and I understand why. Please note that I didn't complain about anything from the start to the end. On the contrary, I admire the work you're doing here. |
FYI, I summarized the conclusion here: lxqt/lxqt#10 (comment) |
By the way, you could try changing the default decoration mode so that Wayfire requests more SSD (default is request CSD). The reasoning for the CSD default is simple, while we have SSD, the default SSDs are actually not very pretty. |
Yes, I'd tried that. By changing decoration settings, I made the SSD title-bar fit menu-bars/primary toolbars of various Kvantum themes to some extent (no gradient). But, of course, shadow was still missing. I really don't know why the developers of qt5-wayland enforced a useless decoration with Wayland. It's rather like a temporary, ugly patch but yes, it's CSD, technically speaking. |
First, I wanted to thank you for this impressive project.
It's very good to see that Qt5 apps run with Wayland by default under Wayfire. But they have non-customizable title-bars and, more importantly, their windows don't drop shadows, as this screenshot shows.
I wouldn't report this if Wayfire didn't already have breathtaking effects like blurring, desktop cube, window rotation, etc.
I have the latest git Wayfire on Manjaro (using AUR's git packages),
The text was updated successfully, but these errors were encountered: