4 ms·

I don't follow all the Wayland compositors but Enlightenment doesn't, and Weston matters here. If somebody really wants this to become standard, implementing it

by zxzax 5y ago

I don't follow all the Wayland compositors but Enlightenment doesn't, and Weston matters here. If somebody really wants this to become standard, implementing it in Weston should be priority. Every compositor library I've looked at also considers this optional, e.g. mir, qtwayland, wlroots.

Cloudef 5y ago
Considering it got xdg prefix and was included in wayland-protocols that should be as standard as it gets. Weston is barebones "reference" compositor. It's not for normal use. Mir is dead. The xdg-decoration is based on KDE's own protocol, it was later refined and pushed to wayland-protocols by wlroots devs. Now kde uses the xdg-decoration too. >Every compositor library I've looked at also considers this optional Because that's the point of it. If compositor doesn't implement it, application would have to fallback to CSD (however very inconvenient for many apps, or users who suddenly will not see a decoration due to purely _technical reasons_), and even when it's implemented, application have to explicitly ask for compositor to decorate the window.
- zxzax 5y ago
  Inclusion in wayland-protocols means that it had enough support without opposition. It doesn't mean that all the members are interested in implementing the feature. According to the members list, Weston and Mir are still important enough to have a vote: https://gitlab.freedesktop.org/wayland/wayland-protocols/-/blob/main/MEMBERS.md https://gitlab.freedesktop.org/wayland/wayland-protocols/-/b... >application have to explicitly ask for compositor to decorate the window. My reading of the protocol is that even when the application asks for that, the compositor can still reject it, and the application must always provide a fallback to CSD.
  - Cloudef 5y ago
    >My reading of the protocol is that even when the application asks for that, the compositor can still reject it, and the application must always provide a fallback to CSD. Yes this is correct too. I assume it was mainly put there for GNOME :) I honestly don't fathom why you would want to be CSD only in general purpose compositor aimed for desktop users. It can make sense in specialized cases. But then again I believe GNOME doesn't want normal users, but rather users that will always do what they want them to do, aka the Apple mentality. This is all made worse with the low-level libraries and programs that don't use the gnome toolkit, end up just drawing some very primitive title bar (sometimes even without any buttons), just so people can drag the window around under gnome compositor. I guess this is the kind of end user experience gnome devs want? Nah, they'll just tell users to use only their apps instead next.
    - zxzax 5y ago
      >I believe GNOME doesn't want normal users, but rather users that will always do what they want them to do, aka the Apple mentality. I would not say this is true, GNOME just handles extensibility differently. If you want to help with this, please consider working on this issue: https://gitlab.gnome.org/GNOME/mutter/-/issues/1053 https://gitlab.gnome.org/GNOME/mutter/-/issues/1053 That would pave the way for GNOME shell extensions to implement window decorations (and other wayland extensions) in a way that doesn't burden upstream maintainers and make them have to support every custom wayland protocol that is only used by a handful of apps. >I guess this is the kind of end user experience gnome devs want? I can't speak for them but I think they would suggest that those low level libraries all collaborate on a shared library to implement nice looking CSD, that way there is no code duplication and no dependence on GNOME libraries. Another option would be for them to copy the approach used by firefox, and use dlopen to access gtk functions and draw the CSD that way when it's detected they're running in a GNOME environment. Such functionality could be put in a library and wrapped up in 1-2 function calls, to make it easy to use. SSD might be the approach used by other desktops, but it is not the only way to achieve this functionality, and it may not even be the simplest.
      - Cloudef 5y ago
        What actually will happen is that those developers either will ignore gnome, force the application to run under xwayland if it detects mutter, or implement a really primitive decoration that will make users open bug reports "why is the decoration so weird?". They'll be taking similar stance as gnome devs and start telling users "it's not our bug", "report it to gnome devs". https://github.com/mpv-player/mpv/issues/3646 https://github.com/mpv-player/mpv/issues/3646 >SSD might be the approach used by other desktops, but it is not the only way to achieve this functionality, and it may not even be the simplest. Surely zero code in client is the "simplest". It also makes sure the decoration always works and behaves the same way in every application. It also won't stop working if the application freezes. Sure with a magical library that you managed to force on everyone at least the consistency and "not buggy" could be solved. But why is this necessary when others don't need it? And I surely don't want to see, libkde-decoration.so, libgnome-decoration.so, libwhatever-decoration.so Here is also very good technical writeup on CSDs from author of yet another display server, that's not wayland nor X11 https://arcan-fe.com/2018/01/27/argumenting-client-side-decorations/ https://arcan-fe.com/2018/01/27/argumenting-client-side-deco...

by zxzax 5y ago

Cloudef 5y ago

Considering it got xdg prefix and was included in wayland-protocols that should be as standard as it gets. Weston is barebones "reference" compositor. It's not for normal use. Mir is dead. The xdg-decoration is based on KDE's own protocol, it was later refined and pushed to wayland-protocols by wlroots devs. Now kde uses the xdg-decoration too. >Every compositor library I've looked at also considers this optional Because that's the point of it. If compositor doesn't implement it, application would have to fallback to CSD (however very inconvenient for many apps, or users who suddenly will not see a decoration due to purely _technical reasons_), and even when it's implemented, application have to explicitly ask for compositor to decorate the window.

zxzax 5y ago
Inclusion in wayland-protocols means that it had enough support without opposition. It doesn't mean that all the members are interested in implementing the feature. According to the members list, Weston and Mir are still important enough to have a vote: https://gitlab.freedesktop.org/wayland/wayland-protocols/-/blob/main/MEMBERS.md https://gitlab.freedesktop.org/wayland/wayland-protocols/-/b... >application have to explicitly ask for compositor to decorate the window. My reading of the protocol is that even when the application asks for that, the compositor can still reject it, and the application must always provide a fallback to CSD.
- Cloudef 5y ago
  >My reading of the protocol is that even when the application asks for that, the compositor can still reject it, and the application must always provide a fallback to CSD. Yes this is correct too. I assume it was mainly put there for GNOME :) I honestly don't fathom why you would want to be CSD only in general purpose compositor aimed for desktop users. It can make sense in specialized cases. But then again I believe GNOME doesn't want normal users, but rather users that will always do what they want them to do, aka the Apple mentality. This is all made worse with the low-level libraries and programs that don't use the gnome toolkit, end up just drawing some very primitive title bar (sometimes even without any buttons), just so people can drag the window around under gnome compositor. I guess this is the kind of end user experience gnome devs want? Nah, they'll just tell users to use only their apps instead next.
  - zxzax 5y ago
    >I believe GNOME doesn't want normal users, but rather users that will always do what they want them to do, aka the Apple mentality. I would not say this is true, GNOME just handles extensibility differently. If you want to help with this, please consider working on this issue: https://gitlab.gnome.org/GNOME/mutter/-/issues/1053 https://gitlab.gnome.org/GNOME/mutter/-/issues/1053 That would pave the way for GNOME shell extensions to implement window decorations (and other wayland extensions) in a way that doesn't burden upstream maintainers and make them have to support every custom wayland protocol that is only used by a handful of apps. >I guess this is the kind of end user experience gnome devs want? I can't speak for them but I think they would suggest that those low level libraries all collaborate on a shared library to implement nice looking CSD, that way there is no code duplication and no dependence on GNOME libraries. Another option would be for them to copy the approach used by firefox, and use dlopen to access gtk functions and draw the CSD that way when it's detected they're running in a GNOME environment. Such functionality could be put in a library and wrapped up in 1-2 function calls, to make it easy to use. SSD might be the approach used by other desktops, but it is not the only way to achieve this functionality, and it may not even be the simplest.
    - Cloudef 5y ago
      What actually will happen is that those developers either will ignore gnome, force the application to run under xwayland if it detects mutter, or implement a really primitive decoration that will make users open bug reports "why is the decoration so weird?". They'll be taking similar stance as gnome devs and start telling users "it's not our bug", "report it to gnome devs". https://github.com/mpv-player/mpv/issues/3646 https://github.com/mpv-player/mpv/issues/3646 >SSD might be the approach used by other desktops, but it is not the only way to achieve this functionality, and it may not even be the simplest. Surely zero code in client is the "simplest". It also makes sure the decoration always works and behaves the same way in every application. It also won't stop working if the application freezes. Sure with a magical library that you managed to force on everyone at least the consistency and "not buggy" could be solved. But why is this necessary when others don't need it? And I surely don't want to see, libkde-decoration.so, libgnome-decoration.so, libwhatever-decoration.so Here is also very good technical writeup on CSDs from author of yet another display server, that's not wayland nor X11 https://arcan-fe.com/2018/01/27/argumenting-client-side-decorations/ https://arcan-fe.com/2018/01/27/argumenting-client-side-deco...