Open DiceySai opened 3 years ago
It's not possible to "extend" client area to decorations with X11 since decorations are drawn by the window manager.
At some point we'll implement client decorations though.
@kekekeks Is that...different from the client-side decorations Avalonia already has for use on Windows as of 0.10.0?
@Splitwirez in 0.10.0 it's Windows specific, IIRC
It's not possible to "extend" client area to decorations with X11 since decorations are drawn by the window manager.
At some point we'll implement client decorations though.
Do you think with Wayland this will be possible?
Wayland either works in the same way as X11 (with xdg_decoration protocol) or asks the app to draw the frame itself. It's not advised to run with client decorations since it breaks window interactions in pretty much desktop anu environment except GNOME.
Hi kekekeks. I would like to fill in that xdg_decoration protocol is an OPTIONAL protocol for desktop environment, but client decorations is MANDATORY. Gnome doesn't implement xdg_decoration and has said it will never do it. Wayland applications are REQUIRED to support client decorations - but NOT xdg_decoration. KDE doesn't like client-decorations but support it because otherwise they break compatibility with the xdg-shell - se https://blog.vladzahorodnii.com/2020/07/23/csd-support-in-kwin/
There has been much politics about client-side decoration vs server-side decorations in Wayland. (https://gitlab.gnome.org/GNOME/mutter/-/issues/217) Regardless one's view, by the Waylands standards (their protocols really) your recommendation is incorrect because Client decorations is GUARANTEED to be supported, while xdg_decoration IS NOT.
Yeah, that's why I've said that wayland "asks the app to draw the frame itself".
In the case when Wayland compositor doesn't support xdg_decoration (or tells us that it wants us to draw the frame), we'll just reuse our managed frame that we are currently drawing for Windows 10.
To be clear: we'll be recommending to use server decorations when they are available because pretty much every non-GNOME setup has advanced window interactions. e. g.
KDE:
Sway and other tiling WMs don't want the window to have any frame because minimize, maximize and drag don't really have any meaning with tiling window compositors.
Kiosk-like compositors only have one fullscreen window, so frame is kinda useless
For a rare case when application developer deliberately ignores their user's preferences and _actively seeks__ to break UX, there will be an option to enforce CSD. Once we get there, that option will also be available for X11. After all, who are we to judge.
For not one can set HasSystemDecorations
property to false
, add a custom frame and go on their merry way.
Here is an example of implementing CSD in your app: https://github.com/VitalElement/AvalonStudio.Shell/blob/01695b95b9e16f18e0d923f67d34e44d3cdb842d/src/AvalonStudio.Shell/Controls/MetroWindow.cs https://github.com/VitalElement/AvalonStudio.Shell/blob/01695b95b9e16f18e0d923f67d34e44d3cdb842d/src/AvalonStudio.Shell/Controls/MetroWindow.paml#L1
While I somewhat disagree with your overall recommendation - that SSD is superior to CSD, I think you could improve your recommendation by adding:
"If you wish to be fully compatible with different Wayland compositors in Linux, you should query in runtime if the Wayland compositor only support CSD. If so you should render your own header."
In one way I think its funny that you recommend SSD, when Avalonia is an gigantic CSD application that do all the rendering yourself :-) - you don't use native control - why use native header? But regardless - I think your recommendations are sound 👍.
that SSD is superior to CSD
They are not superior. It's just some desktop environments rely on server side decorations to work properly, some do not. Application should follow DE preference, which is coincidentally the user's preference. If one wanted to have apps with CSD, they wouldn't have installed a compositor that uses SSD.
Anything new here?
Will this be fixed? I was trying to follow the how to open a popup dialog tutorial (https://docs.avaloniaui.net/tutorials/music-store-app/opening-a-dialog) and that looks especially bad when the native top bar of the window doesn't get hidden (also the popup positioning is way off but I think I remember seeing a separate issue about that).
Describe the bug System: Kylin 20.04
To Reproduce Set custom title tar, and hidden origin with ExtendClientAreaToDecorationsHint = "true", the window will display two title bar. And CanResize= false, also not working.