3 ms·
Agreed. The blog post's author ignores that the GNOME project isn't willing to support basic interoperability with other software, and instead wants to make a G
by ndiddy 4y ago
Agreed. The blog post's author ignores that the GNOME project isn't willing to support basic interoperability with other software, and instead wants to make a GNOME-exclusive ecosystem. The GNOME project's refusal to support XDG-Decoration (https://gitlab.gnome.org/GNOME/mutter/-/issues/217 https://gitlab.gnome.org/GNOME/mutter/-/issues/217) means that even if you're writing something like a game and not using any of the system's UI, you either have to add GTK as a dependency to get the "correct looking" titlebars or spend useful development time writing shitty, non-native looking window decorations just for GNOME users. It's not just "if you disagree with our UI decisions, don't use our DE", it's "we want the Linux desktop platform to match our uncompromised vision and we will make it as annoying as possible for GNOME users to run your software if you disagree".
- znpy 4y ago> The blog post's author ignores that the GNOME project isn't willing to support basic interoperability with other software, and instead wants to make a GNOME-exclusive ecosystem. Does it, though? "My way or the highway" fits very well in this context. "My way or the highway" can also be interpreted as "we don't give a single shit about other software and other people, and we don't care about interoperating with them". Basically GNOME is living in and pushing a world where there's only GNOME. And this is where things get tricky and I feel for the supposed "haters": so now you (GNOME) are a big project and you're pushing your own incompatible and non-interoperable stuff. Some projects will adhere, some won't, for any reason. So now if I'm using anything not GNOME my desktop experience is broken, because software that assume GNOME is running won't work well (if at all) in other environments. It just wasn't this bad before GNOME3 and this mentality shift.
- QUrprUd1nCeicw 4y ago>Basically GNOME is living in and pushing a world where there's only GNOME. No, that's false. I can't see why you'd even think that. GNOME wouldn't be using Wayland at all if that were true. GNOME uses standards where they make sense, this one optional non-standard part of Wayland just happens to not make any sense for GNOME. They don't have any issue with the rest of Wayland.
- chris_wot 4y agoIt’s not false. Not supporting decorations actively causes problems for non-GNOME software.
- QUrprUd1nCeicw 4y agoNo. How would that even make sense? If you have no GNOME-related software on your computer at all then it won't affect it.
- QUrprUd1nCeicw 4y ago>you either have to add GTK as a dependency to get the "correct looking" titlebars or spend useful development time writing shitty, non-native looking window decorations just for GNOME users That's a false dilemma. You don't have to do either of those. The alternate solution is mentioned in that issue: use libdecor. I'll also note, if you refuse to use any of the system's UI and you insist on implement everything yourself directly on libwayland then that's an entirely self-inflicted problem that you created. Libwayland is fairly low-level, it isn't a game development API. Besides window decorations, you'll have lots of other deficiencies and things you have to spend development time on. That's what you volunteered for, GNOME can't help you with that.
- Snetry 4y agoI mean, yeah, you don't need the whole GTK library for titlebars, but you still need to drag libdecor along to support a subgroup (Wayland users) of a subgroup (Gnome users). Its pretty annoying to add another moving piece to the machinery just to do that.
- QUrprUd1nCeicw 4y agoThat's the way it is with any optional X11 or Wayland extension. Either you implement the extension yourself, or you use a library to implement it for you. Typically the code to do this is put in a toolkit, but you decided to write your own toolkit so you get to deal with the annoyance. Nothing's changed in this regard. Actually, most optional things in Linux are like this and it's been this way since shared libraries were implemented. If you find the idea of this so off-putting, maybe you should be using a pre-made toolkit instead of writing your own?