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.
Decorations can be done client-side with a library if needed - there is no reason to push that work to the compositor.
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.
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.
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.
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.
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.
When is it appropriate to assume bad faith? I think assuming bad faith can be very helpful if only because it tells you what to not support or depend on.
Saying "you have to use our library and also fix it for free" is a dick move regardless.
>I think assuming bad faith can be very helpful if only because it tells you what to not support or depend on.
I'm sorry I don't get what you're saying. You can decide not to support or depend on something without (incorrectly) assuming bad faith. This stuff is all open source, nobody can force you to use a library that you're not interested to use.
That's not strictly speaking true, especially when politics and money get involved. Unless you're using a very loose definition of "force" which doesn't include any kind of network effect at all.
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.
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.
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.,
Old apps should dynamically link SDL / Gtk+ / Qt so they should work. For other old apps there's Xwayland which still provides SSD in GNOME.
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.
It's not breaking GTK apps. If they want to say GNOME really only works with GTK apps that's fine and the toolkit will provide the decorations and nobody needs to care which part of the system draws them. But they want to support more than just GTK apps and rightly so.
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.