3 ms·

>mpv has since implemented client side decorations. Yes eventually somebody implemented them, and they look like this: https://github.com/mpv-player/mpv/pull/7

>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
    SSD only isn't really an option, from what I have seen, eventually app designers want CSD to reduce clutter and to give their apps a better native look. This is true on all platforms, see for example macOS Big Sur. >This is if they actually are. They are, you would see terrible breakage with every app if they weren't. Your dynamic linker is effectively using dlopen/dlsym under the hood, it's not doing any type checking.
    - Cloudef 5y ago
      >SSD only isn't really an option, from what I have seen, eventually app designers want CSD to reduce clutter and to give their apps a better native look. This is true on all platforms, see for example macOS Big Sur. This isn't about the look of applications. This is about the needs of users and developers. I personally don't have window decorations at all on my main system, I don't need them and they are useless. There's developers that ask GNOME devs to implement a feature so their app can continue to work with GNOME users. There's users that ask GNOME devs to implement a feature so that app can work in GNOME. That's the point I'm trying to drive in here. GNOME devs feel like they can just break existing behaviors and ecosystems if they feel like it and say the problem is not on their end, while other groups have cooperated and worked on a solution that works for everyone. This is also the reason I don't use wayland nor develop anything for it anymore, too many things just don't work there, and the people that actually are trying to make things work or at least work on replacements gets constantly ignored or told to go away, meanwhile a single person has done a display server, that is not just wayland and xorg compatible, it's also much more flexible and more powerful than wayland ever is going to be. https://arcan-fe.com https://arcan-fe.com >Your dynamic linker is effectively using dlopen/dlsym under the hood, it's not doing any type checking. What I mean by typechecking is that with typical linkage + header scenario you get compile error if API changed (this won't prevent ABI breakage however). With dlopen/dlsym, if you have typo in your function pointer declarations, that can be hard to debug bug. Sure this can be avoided to make sure you generate such pointers from upstream headers and keep them up-to-date. There's also some other unrelated issues that can rise from this, like package maintainers having trouble to figure out what the real dependencies (or even the optional dependencies) of the application actually are, I've been there.

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
  SSD only isn't really an option, from what I have seen, eventually app designers want CSD to reduce clutter and to give their apps a better native look. This is true on all platforms, see for example macOS Big Sur. >This is if they actually are. They are, you would see terrible breakage with every app if they weren't. Your dynamic linker is effectively using dlopen/dlsym under the hood, it's not doing any type checking.
  - Cloudef 5y ago
    >SSD only isn't really an option, from what I have seen, eventually app designers want CSD to reduce clutter and to give their apps a better native look. This is true on all platforms, see for example macOS Big Sur. This isn't about the look of applications. This is about the needs of users and developers. I personally don't have window decorations at all on my main system, I don't need them and they are useless. There's developers that ask GNOME devs to implement a feature so their app can continue to work with GNOME users. There's users that ask GNOME devs to implement a feature so that app can work in GNOME. That's the point I'm trying to drive in here. GNOME devs feel like they can just break existing behaviors and ecosystems if they feel like it and say the problem is not on their end, while other groups have cooperated and worked on a solution that works for everyone. This is also the reason I don't use wayland nor develop anything for it anymore, too many things just don't work there, and the people that actually are trying to make things work or at least work on replacements gets constantly ignored or told to go away, meanwhile a single person has done a display server, that is not just wayland and xorg compatible, it's also much more flexible and more powerful than wayland ever is going to be. https://arcan-fe.com https://arcan-fe.com >Your dynamic linker is effectively using dlopen/dlsym under the hood, it's not doing any type checking. What I mean by typechecking is that with typical linkage + header scenario you get compile error if API changed (this won't prevent ABI breakage however). With dlopen/dlsym, if you have typo in your function pointer declarations, that can be hard to debug bug. Sure this can be avoided to make sure you generate such pointers from upstream headers and keep them up-to-date. There's also some other unrelated issues that can rise from this, like package maintainers having trouble to figure out what the real dependencies (or even the optional dependencies) of the application actually are, I've been there.