I think you don't mean that the Wayland protocol forces slowness but that the compositor you used was slow. The one I use is fast.
> And if you don't like the window decorations (say, they take up too much screen space) your choices are suck it up, or if you're lucky and willing to spend a bunch of time reconfigure every different toolkit your apps use.
No, there are protocols to negotiate whether an app has server side decoration or not and the compositor has the last say.
> basic stuff that worked fine on X11 doesn't work on wayland in the name of "security"
On only the core Wayland protocols you're absolutely correct, you can't even implement desktop shells with those. This means there must be extensions and there are 3 different classes: KDE, GNOME, wlroots, with tools for and incompatibility between each. The wlroots extensions are designed to be accepted into the standard and for wider Wayland acceptance they probably should be.
Screen sharing is still a particular issue that we are starting to see solved with the advent of Pipewire.
Wayland desktops are definitely usable. I've been happy with a wlroots based one (Wayfire) for a few months and KDE before that (from what I see GNOME has been perfect for a while).
One of the last standing real issues I'm facing is kerfuffle with Nvidia drivers, especially the ones paired with Intel GPUs, but I think (surprisingly) Nvidia are actually working on fixing that.
> No, there are protocols to negotiate whether an app has server side decoration or not and the compositor has the last say.
The compositor can implement that protocol and just respond with "this compositor doesn't support SSDs". GNOME does this, so all toolkits must use CSDs if they wanna work on the most popular Wayland compositor.
Incidentally, that's hell for all the simple libraries out there which just exist to get a GL window on the screen. GLFW, GLEW, SDL, etc. all have to implement CSDs now if they wanna work with Wayland. It also means that it's no longer feasible to just make a Linux application which uses the windowing system directly; everything must use a huge toolkit now.
EDIT: To clarify, I don't think this is an issue with Wayland, but with GNOME. There's no reason it couldn't have supported SSDs like every other Wayland compositor. But as it stands, it hurts the Wayland ecosystem.
GLFW and SDL are looking at using libdecoration to draw CSDs. Yes it's an additional dependency but most applications won't need to worry about it unless they need it.
The way GNOME is built it's not really possible architecturally for them to support SSDs in Wayland. Maybe that will change if they ever get around to redesigning mutter and gnome-shell, but I wouldn't wait for it.
I've seen libdecoration, and yeah, that seems like their intended solution to this. It doesn't seem like a terrible solution, but last time I looked at it at least, libdecoration was a long way off being production ready, and GNOME with Wayland is shipping _right now_ and must be supported.
You can use a library like that or you can draw your own decorations. There unfortunately is no other option. I don't see it as being likely that GNOME will support SSD any time soon, it just isn't designed for that.
What would it take for something not to qualify as being "unreasonably obstructionist" to you? If there's an open source desktop project that has infinite resources to redesign and rewrite everything at will at a moment's notice, then please let me know. I'll gladly use it. Hell, I'll sign up as a developer.
Have GNOME devs yet acknowledged that XFCE exists? In one now infamous exchange with Transmission developers a GNOME dev claimed that he didn't even know what XFCE was and, furthermore, that cross platform applications like Transmission should choose whether they would be "GNOME apps or XFCE apps", suggesting that they can't be both. The context of this exchange was that GNOME developer asking that a feature be removed from Transmission because GNOME would no longer support it.
That's just one example, but GNOME has a reputation for not respecting Linux desktop diversity for a reason.
I had to dig up the comment you're talking about but just to put this in perspective: You are forming your current opinion about entire communities based on one comment made by one developer 10 years ago. I'm fascinated by all this open source that's out there but if you told me that a developer had to know every single open source desktop out there in order to contribute to one of them then I can't really get behind that. It's very hard to keep track of what everyone's doing all the time.
But in any case I don't understand what is contentious about that. Some pieces are shared between GNOME and XFCE, but a lot of pieces are different and applications have always needed to choose. If they weren't trying to be different they wouldn't have made a separate desktop environment with their own separate libxfce libraries and components. (To GNOME's credit, they have gotten rid of most of the "libgnome" things since then, but now an application that wants to speak to certain GNOME-specific pieces is usually expected to use their private dbus protocols, things that XFCE would never implement anyway)
> You are forming your current opinion about entire communities based on one comment made by one developer 10 years ago
Incorrect. I am using a single example to illustrate a trend. A single example to illustrate what "unreasonably obstructionist" looks like. That particular incident made everybody roll their eyes but it hardly surprised anybody because GNOME has earned this reputation. Even back then nobody was particularly surprised by the GNOME arrogance, and I've not seen this change.
(Also, maybe I'm getting old but 10 years ago really isn't that long ago.)
Please don't use this kind of hyperbole. It's really not an interesting conversation when it leads into platitudes like "everybody did this" and "nobody did that" and "an entire group of people is arrogant and obstructionist" which neither of us have any way of proving or disproving. I wish this open-source-holy-war type of comment was not so common on Reddit and HN, it's about as constructive as the endless Emacs and Vim flame wars.
If you're trying to illustrate the trend that GNOME and XFCE (and KDE, and LXQT, and MATE, and Budgie, and Mint...) all have different goals and ideas for how applications should behave then yes, I would say that much is obvious by now, and it has only gotten more obvious over the last few years. If you have a technical solution to this then I'd love to hear it, but aside from that I don't care to bicker about whose fault it is that your applications broke, because honestly no answer is going to pleasing for you to hear. Unless I'm mistaken then we aren't paying customers, this is all just random no-warranty open source and there's no support hotline that's going to care about what's broken.
Transmission never broke. GNOME devs requested that Transmission break itself on non-GNOME platforms. Falling back on 'well you're not paying anything' really does nothing to dispel the perception that GNOME devs don't play nice with others. If anything, it cements it.
If nothing broke then I don't see what the problem is. And, your assertion doesn't even seem to be correct. I re-read the bug and it's one GNOME developer suggesting for changes to be made only in GNOME 3, because support for a particular feature was deprecated upstream. The developer is apologetic and later goes on to make suggestions about what can be done in Ubuntu and XFCE. I see nothing there about "GNOME devs requesting that Transmission break itself." https://trac.transmissionbt.com/ticket/3685
I'm not trying to dispel any perceptions either, if you have a deep seated belief that GNOME (or XFCE, or anything really) are "not playing nice" because they removed features from upstream, there's nothing I can really say to you to change that view. If you want to challenge your own perceptions, I'd suggest you start developing a new open source desktop and application platform yourself over a period of many years just to see how much work it is, and how it's practically impossible to support everything that every app developer asks for when none of them are paying you a cent.
I was trying to be clear here: There is a reason and it's that it's not really possible architecturally for them to support SSDs in Wayland; doing so would require a redesign of significant parts of the compositor's code. I'm sorry if that was misunderstood. If you're trying to say they should have anticipated this and made a different architectural decision years ago, maybe that's true, but that also offers no practical solution to the applications that need to support it right now.
I am trying to say that maybe they should have made the architectural decisions which wouldn't prevent non-GTK applications from working in GNOME. That's all.
I don't know what you're trying to get at. We can sit here and argue and say they should have done this and they should have done that, but that doesn't help anybody who wants support for them at this current moment.
And please don't exaggerate, non-GTK applications do work in GNOME. Qt5 has native CSDs that will show up in GNOME. If the application is a game or something that doesn't support CSD then the experience is somewhat degraded but they still work. You can resize and move any window by holding Super and Left/Middle clicking. I won't pretend the situation is ideal but I also don't believe it's totally unusable or on a bad trajectory at the moment—like I said the other libraries are working on getting CSD support too.
> GLFW, GLEW, SDL, etc. all have to implement CSDs now if they wanna work with Wayland.
I honestly don't understand what you're talking about here? If you want to get a window on the screen with OpenGL or Vulkan you don't implement anything special for Wayland.
In fact with Vulkan+Wayland, it's fairly easy to do it without any third-party dependencies, with OpenGL you'll probably need EGL which is a Khronos dependency. Here's some slightly outdated example code [1].
If you just create a Wayland window, GNOME will draw _only_ that window, with no decorations. The window can't be moved, minimized, resized, etc. because there's no decorations. The window's content shows up, but that's it.
I don't believe that's correct. The move, minimize, full-screen and resize seems to be part of the xdg_shell protocol (which has no extra methods for decorations and is only for window roles etc...) under the configure event [1]. I suspect that's how the tiling window managers like sway do it without extra server-side decorations.
Possibly this is a subtle distinction, but I do think it matters.
I believe you misread my comment; I said that the full-screen, minimize, re-size isn't part of the server-side decoration extension, but was part of a more basic xdg_shell protocol through the configure event.
I was objecting to the fact that you said that windows did not have this capability without the server-side extensions, whereas I think they can be through configure. I did not dispute whether sway had server-side decorations or not.
> The [compositor] I use is fast. [...] I've been happy with a wlroots based one (Wayfire) for a few months
wlroots performed very poorly on my i5-3427U with 4000 series iGPU. Very poorly. I ended up using neither X nor Wayland and instead having mpv render straight to the frame buffer (--vo=gpu --gpu-context=drm)
I'm a wlroots developer, and I'm using an old Sandybridge mobile i5 CPU daily. So I'm pretty surprised about this. I'd be interested in a bug report if you were to try again.
I'll agree with this post. Wayland is not pleasant on my core i5 machine either. I should point out that the GPU it has is very weak, I don't know what it is but most 3d games are unplayable.
X.org, Firefox, and Xterm all work very well on it though. As do other apps like gschem and openscad.
"Wayland" is just the protocol, can you give more details about your setup? For instance, GNOME is more heavyweight than say Sway (and gives a more feature-ful and eye-candy user experience in return).
I think you don't mean that the Wayland protocol forces slowness but that the compositor you used was slow. The one I use is fast.
> And if you don't like the window decorations (say, they take up too much screen space) your choices are suck it up, or if you're lucky and willing to spend a bunch of time reconfigure every different toolkit your apps use.
No, there are protocols to negotiate whether an app has server side decoration or not and the compositor has the last say.
> basic stuff that worked fine on X11 doesn't work on wayland in the name of "security"
On only the core Wayland protocols you're absolutely correct, you can't even implement desktop shells with those. This means there must be extensions and there are 3 different classes: KDE, GNOME, wlroots, with tools for and incompatibility between each. The wlroots extensions are designed to be accepted into the standard and for wider Wayland acceptance they probably should be.
Screen sharing is still a particular issue that we are starting to see solved with the advent of Pipewire.
Wayland desktops are definitely usable. I've been happy with a wlroots based one (Wayfire) for a few months and KDE before that (from what I see GNOME has been perfect for a while).
One of the last standing real issues I'm facing is kerfuffle with Nvidia drivers, especially the ones paired with Intel GPUs, but I think (surprisingly) Nvidia are actually working on fixing that.