4 ms·

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 re

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...

zxzax 5y ago
>They'll be taking similar stance as gnome devs and start telling users "it's not our bug", "report it to gnome devs". I'm not sure I understand where that happened, the issue you posted is closed, and mpv has since implemented client side decorations. >Surely zero code in client is the "simplest". There aren't any zero code solutions, implementing xdg-decoration in the clients is more than zero lines of code. If you violate the spec and ignore the protocol requirement that the client must provide a CSD fallback then it's not a lot of code but again, you could also provide a library that allows clients to draw a prefab CSD around themselves in a very small amount of code. >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? I've seen other ways those can be achieved without SSD. Implementing a good looking and good behaving SSD that works well with every app is not simple either, and it's always going to be necessary to solve that because the core problem of making good decorations is always the same. >And I surely don't want to see, libkde-decoration.so, libgnome-decoration.so, libwhatever-decoration.so The idea I suggested is for the library to load the relevant kde and gtk symbols with dlopen, so there would not need to be multiple libraries. This I believe is how SDL already operates under the hood for some things.
- Cloudef 5y ago
  >mpv has since implemented client side decorations. Yes eventually somebody implemented them, and they look like this: https://github.com/mpv-player/mpv/pull/7186 https://github.com/mpv-player/mpv/pull/7186 Needless to say, mpv prefers xdg-decoration if compositor supports it. >There aren't any zero code solutions It's zero-code for client if the compositor actually handled the border. And yes, compositor is the more likely component to actually have the foundation to do this kind of task.. I mean it is an _compositor_. >The idea I suggested is for the library to load the relevant kde and gtk symbols with dlopen, so there would not need to be multiple libraries Yes and hope those libraries actually implement stable ABI. SDL may do this, but it's actually a maintenance nightmare. If you actually go this way, it's better to have wrapper libraries that link to the actual libraries instead and dlopen those wrapper libraries where you can ensure stable ABI. Though I also aren't really fan of shared libraries, but that's entirely different topic.
  - zxzax 5y ago
    I assume that screenshot is a joke, the decorations don't look like that for me, they look small and unobtrusive. I actually prefer them to SSD because they take less space, and they are consistent with the way the mpv decorations work in macOS. >It's zero-code for client if the compositor actually handled the border. With respect, it's not. The client still must implement the semantics of the xdg-decoration protocol to tell the compositor that it wants a border. >Yes and hope those libraries actually implement stable ABI. Major versions of Qt and GTK are stable, i.e. if you target Qt5 and Gtk3, that won't change.
    - Cloudef 5y ago
      >I assume that screenshot is a joke, the decorations don't look like that for me, they look small and unobtrusive. I'm not exactly sure how they look like currently, as I don't use gnome (nor wayland), but that was the latest PR regarding CSD I was able to find. >With respect, it's not. The client still must implement the semantics of the xdg-decoration protocol to tell the compositor that it wants a border. Sure in wayland's case. But this is only because both systems needs to be supported. But it could be even more simpler with SSD only. >Major versions of Qt and GTK are stable, i.e. if you target Qt5 and Gtk3, that won't change. This is if they actually are. With dlopen/dlsym, you effectively get rid of all type-checking making the code more fragile.

zxzax 5y ago

>They'll be taking similar stance as gnome devs and start telling users "it's not our bug", "report it to gnome devs". I'm not sure I understand where that happened, the issue you posted is closed, and mpv has since implemented client side decorations. >Surely zero code in client is the "simplest". There aren't any zero code solutions, implementing xdg-decoration in the clients is more than zero lines of code. If you violate the spec and ignore the protocol requirement that the client must provide a CSD fallback then it's not a lot of code but again, you could also provide a library that allows clients to draw a prefab CSD around themselves in a very small amount of code. >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? I've seen other ways those can be achieved without SSD. Implementing a good looking and good behaving SSD that works well with every app is not simple either, and it's always going to be necessary to solve that because the core problem of making good decorations is always the same. >And I surely don't want to see, libkde-decoration.so, libgnome-decoration.so, libwhatever-decoration.so The idea I suggested is for the library to load the relevant kde and gtk symbols with dlopen, so there would not need to be multiple libraries. This I believe is how SDL already operates under the hood for some things.

Cloudef 5y ago
>mpv has since implemented client side decorations. Yes eventually somebody implemented them, and they look like this: https://github.com/mpv-player/mpv/pull/7186 https://github.com/mpv-player/mpv/pull/7186 Needless to say, mpv prefers xdg-decoration if compositor supports it. >There aren't any zero code solutions It's zero-code for client if the compositor actually handled the border. And yes, compositor is the more likely component to actually have the foundation to do this kind of task.. I mean it is an _compositor_. >The idea I suggested is for the library to load the relevant kde and gtk symbols with dlopen, so there would not need to be multiple libraries Yes and hope those libraries actually implement stable ABI. SDL may do this, but it's actually a maintenance nightmare. If you actually go this way, it's better to have wrapper libraries that link to the actual libraries instead and dlopen those wrapper libraries where you can ensure stable ABI. Though I also aren't really fan of shared libraries, but that's entirely different topic.
- zxzax 5y ago
  I assume that screenshot is a joke, the decorations don't look like that for me, they look small and unobtrusive. I actually prefer them to SSD because they take less space, and they are consistent with the way the mpv decorations work in macOS. >It's zero-code for client if the compositor actually handled the border. With respect, it's not. The client still must implement the semantics of the xdg-decoration protocol to tell the compositor that it wants a border. >Yes and hope those libraries actually implement stable ABI. Major versions of Qt and GTK are stable, i.e. if you target Qt5 and Gtk3, that won't change.
  - Cloudef 5y ago
    >I assume that screenshot is a joke, the decorations don't look like that for me, they look small and unobtrusive. I'm not exactly sure how they look like currently, as I don't use gnome (nor wayland), but that was the latest PR regarding CSD I was able to find. >With respect, it's not. The client still must implement the semantics of the xdg-decoration protocol to tell the compositor that it wants a border. Sure in wayland's case. But this is only because both systems needs to be supported. But it could be even more simpler with SSD only. >Major versions of Qt and GTK are stable, i.e. if you target Qt5 and Gtk3, that won't change. This is if they actually are. With dlopen/dlsym, you effectively get rid of all type-checking making the code more fragile.