4 ms·

If that's your best argument against Gnome it seems like they are doing pretty well. Decorations can be done client-side with a library if needed - there is no

If that's your best argument against Gnome it seems like they are doing pretty well. Decorations can be done client-side with a library if needed - there is no reason to push that work to the compositor.

Cloudef 5y ago
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.
simion314 5y ago
And now Qt, Electron, games , old programs will need to do extra work to satisfy a GNOME designer ego. you could always tell the window manager not to paint the decorations and you could have your own cool decorations (using a library if you want). From my point of view this looks that GNOME is force pushing their vision to all their users and all GTK users unfortunately.
- jhasse 5y ago
  Electron uses Gtk and Games should use SDL2. They will support CSD, which is work, but it will happen. You could also say that SSD would mean that Mutter needs to do extra work just to satisfy an application designer ego. Btw: I'm a GNOME user who is against SSD.
  - simion314 5y ago
    The issue is that Electron and SDL will fix this 10 years later, old apps will still not work. Same issue with tray icons, GNOME is expecting cross platform apps will use their shirty design OR their users will use only new GNOME apps. >You could also say that SSD would mean that Mutter needs to do extra work just to satisfy an application designer ego Is better that say all the 10 WM implement SSD (maybe as a fallback for old or non native apps) rather then force all toolkits and old apps have to implement this how they think (won't you get apps that will look like XP or OSX because you forced the app to paint the buttons). As a developer myself feels rather stupid not to just provide the SSD for old apps , really feels like "let's make this old and non native apps look and work like shit so people use my cool design. But I could see an argument that GNOME devs are not that competent though, they implemented a shell that will kill all your apps if there is an error in an exception(on wayland)... so incompetence could explain why they are not capable to provide both SSD and CSD too.,
    - zxzax 5y ago
      > The issue is that Electron and SDL will fix this 10 years later, old apps will still not work. The SSD in GNOME still works for X11 apps. For now the only path for old apps that need SSD is to continue using the X11 backend in Electron and SDL. For GNOME, SSD was never in the plan with wayland, so this is not breaking compatibility with apps there because it was never supported.
anonymousab 5y ago
Someone posting a fairly reasonable use case and solution problem summary, and then getting the response of "Spam. Closed." does not seem like a reasonable project by any stretch of the imagination. Quite frankly, taking 5 minutes to put up a page saying "We will never support SSD and we acknowledge the use cases but do not care about them." would be far more forthright.
phkahler 5y ago
>> Decorations can be done client-side with a library if needed - there is no reason to push that work to the compositor. In a wayland system the compositor IS the desktop shell. Window placement is not up to the application, so moving them and hence putting "handles" on them in the form of decorations is a natural fit for the compositor. Another feature that belongs in the compositor is remembering where each application was last placed and sized and replicating that when starting them. I agree with the Wayland ideas that programs do not have the ability to warp mouse pointer or know about their environment, but once that model has been adopted there are useful features that need to move (or for decorations should move) into the compositor.
fiddlerwoaroof 5y ago
This is exactly why I’m sticking with X as long as possible. CSD makes absolutely no sense to me: under no conceivable circumstances do I want the window decorations to depend on which toolkit someone chose to use: it works out ok on macOS, I guess, but Windows/Linux each have their own issues with apps not having a consistent look and feel, and this just exacerbates that.

Cloudef 5y ago

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.

simion314 5y ago

And now Qt, Electron, games , old programs will need to do extra work to satisfy a GNOME designer ego. you could always tell the window manager not to paint the decorations and you could have your own cool decorations (using a library if you want). From my point of view this looks that GNOME is force pushing their vision to all their users and all GTK users unfortunately.

jhasse 5y ago
Electron uses Gtk and Games should use SDL2. They will support CSD, which is work, but it will happen. You could also say that SSD would mean that Mutter needs to do extra work just to satisfy an application designer ego. Btw: I'm a GNOME user who is against SSD.
- simion314 5y ago
  The issue is that Electron and SDL will fix this 10 years later, old apps will still not work. Same issue with tray icons, GNOME is expecting cross platform apps will use their shirty design OR their users will use only new GNOME apps. >You could also say that SSD would mean that Mutter needs to do extra work just to satisfy an application designer ego Is better that say all the 10 WM implement SSD (maybe as a fallback for old or non native apps) rather then force all toolkits and old apps have to implement this how they think (won't you get apps that will look like XP or OSX because you forced the app to paint the buttons). As a developer myself feels rather stupid not to just provide the SSD for old apps , really feels like "let's make this old and non native apps look and work like shit so people use my cool design. But I could see an argument that GNOME devs are not that competent though, they implemented a shell that will kill all your apps if there is an error in an exception(on wayland)... so incompetence could explain why they are not capable to provide both SSD and CSD too.,
  - zxzax 5y ago
    > The issue is that Electron and SDL will fix this 10 years later, old apps will still not work. The SSD in GNOME still works for X11 apps. For now the only path for old apps that need SSD is to continue using the X11 backend in Electron and SDL. For GNOME, SSD was never in the plan with wayland, so this is not breaking compatibility with apps there because it was never supported.

anonymousab 5y ago

Someone posting a fairly reasonable use case and solution problem summary, and then getting the response of "Spam. Closed." does not seem like a reasonable project by any stretch of the imagination. Quite frankly, taking 5 minutes to put up a page saying "We will never support SSD and we acknowledge the use cases but do not care about them." would be far more forthright.

phkahler 5y ago

>> Decorations can be done client-side with a library if needed - there is no reason to push that work to the compositor. In a wayland system the compositor IS the desktop shell. Window placement is not up to the application, so moving them and hence putting "handles" on them in the form of decorations is a natural fit for the compositor. Another feature that belongs in the compositor is remembering where each application was last placed and sized and replicating that when starting them. I agree with the Wayland ideas that programs do not have the ability to warp mouse pointer or know about their environment, but once that model has been adopted there are useful features that need to move (or for decorations should move) into the compositor.

fiddlerwoaroof 5y ago

This is exactly why I’m sticking with X as long as possible. CSD makes absolutely no sense to me: under no conceivable circumstances do I want the window decorations to depend on which toolkit someone chose to use: it works out ok on macOS, I guess, but Windows/Linux each have their own issues with apps not having a consistent look and feel, and this just exacerbates that.