3 ms·

Sure you can do everything with a library, and that's how you end up with library hell, or dependencies that will be hard to get rid of or replaced later, becau

Sure you can do everything with a library, and that's how you end up with library hell, or dependencies that will be hard to get rid of or replaced later, because how big they become or how broken the API was (e.g. fontconfig). But being the only ecosystem where that's needed is pushing some heavy boilerplate on developers. Why would games, or non-gnome apps care about decoration? There's plenty of good examples of applications where the decoration being forced on them doesn't make sense. The protocol is also standardized and gnome is the only wayland compositor that refuses to implement it, this is not the only case where gnome devs just decide to be jerks. Things like these are why I think I'll never will be using wayland as it just breaks everyone's existing applications and workflows. wlroots and sway developers are doing good work to try to bring wayland and its tools to same level as X11, but then we have these other groups that just actively reject anything that doesn't go along with their "vision". And I speak as someone who wrote one of the first wayland compositors, and one of the first wayland compositor libraries, which code partially still exists in wlroots.

zxzax 5y ago
>Why would games, or non-gnome apps care about decoration? I don't think they would which is why the low level toolkits like SDL are the ones that have to handle it. Unfortunately that's the way it is, libwayland is very barebones and doesn't have a way to draw decorations. >this is not the only case where gnome devs just decide to be jerks. Please do not assume bad faith and suggest that someone is being a jerk to you personally because they didn't implement a feature that you were interested in. This is a sure fire way to cause burnout and stress to open source developers. >wlroots and sway developers are doing good work to try to bring wayland and its tools to same level as X11, but then we have these other groups that just actively reject anything that doesn't go along with their "vision". I have seen wlroots and sway developers reject patches and features that don't go along with their vision too, so I am not sure what distinction you're trying to draw.
- Cloudef 5y ago
  Considering the bug report has lots of examples of why they need SSD or at least some other solution (libgtk doesn't work for all the use cases, e.g. vulkan, libdecoration doesn't look "native"), also including constructive feedback, but the gnome devs close it with reply "Enough spam for today. Locking the issue.", I consider them to be quite the jerks indeed.
  - akvadrako 5y ago
    If you don't care about drawing decorations I don't see why you would care if it looks native. It can never really look or behave natively on Gnome since client-side decorations are more than a boarder and window buttons. It's also about having an integrated toolbar and more draggable area.
    - freshair 5y ago
      > "If you don't care about drawing decorations I don't see why you would care if it looks native." Don't you have this completely backwards? If I want my application to have special custom decorations, then it makes sense for my application to draw the decorations. But if I want my application to have the standard decorations of the system, why should I want my application draw them? GNOME supporting SSDs would not diminish the ability of GNOME's applications to use CSDs. So objections about the utility of CSDs imply a false dichotomy.
  - zxzax 5y ago
    >libgtk doesn't work for all the use cases, e.g. vulkan, libdecoration doesn't look "native" The solution there would be to fix gtk to support vulkan, and to fix libdecoration so it looks better. >I consider them to be quite the jerks indeed. Please stop, this is assuming bad faith and it's not helpful. The mutter bug tracker is an inappropriate place to give this unrelated feedback about this, when those issues you talked about are problems in libgtk and libdecoration. That's why the issue is closed. If you are just going to throw flames and don't want to discuss real technical solutions to the problem then I'm going to end the conversation.
    - 5y ago

zxzax 5y ago

>Why would games, or non-gnome apps care about decoration? I don't think they would which is why the low level toolkits like SDL are the ones that have to handle it. Unfortunately that's the way it is, libwayland is very barebones and doesn't have a way to draw decorations. >this is not the only case where gnome devs just decide to be jerks. Please do not assume bad faith and suggest that someone is being a jerk to you personally because they didn't implement a feature that you were interested in. This is a sure fire way to cause burnout and stress to open source developers. >wlroots and sway developers are doing good work to try to bring wayland and its tools to same level as X11, but then we have these other groups that just actively reject anything that doesn't go along with their "vision". I have seen wlroots and sway developers reject patches and features that don't go along with their vision too, so I am not sure what distinction you're trying to draw.

Cloudef 5y ago
Considering the bug report has lots of examples of why they need SSD or at least some other solution (libgtk doesn't work for all the use cases, e.g. vulkan, libdecoration doesn't look "native"), also including constructive feedback, but the gnome devs close it with reply "Enough spam for today. Locking the issue.", I consider them to be quite the jerks indeed.
- akvadrako 5y ago
  If you don't care about drawing decorations I don't see why you would care if it looks native. It can never really look or behave natively on Gnome since client-side decorations are more than a boarder and window buttons. It's also about having an integrated toolbar and more draggable area.
  - freshair 5y ago
    > "If you don't care about drawing decorations I don't see why you would care if it looks native." Don't you have this completely backwards? If I want my application to have special custom decorations, then it makes sense for my application to draw the decorations. But if I want my application to have the standard decorations of the system, why should I want my application draw them? GNOME supporting SSDs would not diminish the ability of GNOME's applications to use CSDs. So objections about the utility of CSDs imply a false dichotomy.
- zxzax 5y ago
  >libgtk doesn't work for all the use cases, e.g. vulkan, libdecoration doesn't look "native" The solution there would be to fix gtk to support vulkan, and to fix libdecoration so it looks better. >I consider them to be quite the jerks indeed. Please stop, this is assuming bad faith and it's not helpful. The mutter bug tracker is an inappropriate place to give this unrelated feedback about this, when those issues you talked about are problems in libgtk and libdecoration. That's why the issue is closed. If you are just going to throw flames and don't want to discuss real technical solutions to the problem then I'm going to end the conversation.
  - 5y ago