4 ms·
This is becoming pointless when you are saying things like this: > It is the status quo on GNOME. This is your problem, and GNOME's too: GNOME doesn't own the
by jchw 5y ago
This is becoming pointless when you are saying things like this:
> It is the status quo on GNOME.
This is your problem, and GNOME's too: GNOME doesn't own the Linux desktop. The status quo on GNOME should not drive protocol standards that impact the entire Linux desktop ecosystem. The protocol standards should be driven by the needs of the larger ecosystem. I'm not saying the needs of GNOME are unimportant. They are just not the end of what needs to be considered when developing this kind of thing.
This point here is more important than this entire argument about CSD. The rest can be discarded. Why should GNOME's fairly isolated status quo be the burden of every application or app toolkit developer? The inverse is a burden on the compositor. There are far more apps and app developers, and even toolkits, than there will ever be Wayland compositors.
> It works fine. Why would it be a problem? It's not different from adding any other library dependency to a flatpak.
Because you will get a vendored copy of libdecor. In a runtime like the Steam runtime, you might wind up attempting to load a version of libdecor linked against an incompatible libc if you try to use the system version. This is not a problem that would occur if a protocol were used instead.
> This isn't true, and it also has the potential to create other problems. What you are missing is that the protocol doesn't really matter, what matters is having a good experience for the user.
libdecor also has the potential to create other problems. This is just pointing out that software is hard. Yes, I get that.
If GNOME cared about what experience was good for the user, they would have cared about the fact that the Wayland compositor they shipped into production runs many games with missing window borders because of their own initiatives and sway within the Wayland ecosystem. The user experience in GNOME is genuinely worse due to this strange insistence on moving a problem from one location to another.
> I don't agree with this either, the complexity and ugliness has moved to libdecor which gets used by the toolkit. App developers don't have to bother with the details, they just use a toolkit.
Not every application needs a UI toolkit. There are also a lot of UI toolkits. Now many of them struggle with the fairly unimpressive task of displaying a window with reasonable looking borders. That's not a good user experience, and it's certainly not a good developer experience.
I really do have a lot of opinions regarding what you are saying, but I'm honestly running out of steam on replying to each point blow-for-blow because it feels like I already expressed my point and the reply is just what I said but inverted.
- BrightGlow 5y ago>This is your problem, and GNOME's too: GNOME doesn't own the Linux desktop. I'm sorry I have no idea what you mean. This is not about the Linux desktop, this is about GNOME. If you don't want to support GNOME then there's no reason to discuss this, because it doesn't matter, you can keep going about your way and you don't have to care about them. Am I missing something here? >The status quo on GNOME should not drive protocol standards that impact the entire Linux desktop ecosystem. Why should GNOME's fairly isolated status quo be the burden of every application or app toolkit developer? They aren't, and they don't? I'm extremely confused as to what you're talking about here. This again is about what you would have to do to support GNOME. Not any other Linux desktop. >The inverse is a burden on the compositor. There are far more apps and app developers, and even toolkits, than there will ever be Wayland compositors. This doesn't matter because the issue here is how to make apps that aren't broken. Some things simply cannot be fixed in the compositor, they have to be fixed in the app, and this is one of them. I sympathize with your concern and I wish it wasn't the case, but sometimes app developers have to do some work that they don't want to do. >Because you will get a vendored copy of libdecor. In a runtime like the Steam runtime, you might wind up attempting to load a version of libdecor linked against an incompatible libc if you try to use the system version. This is not a problem that would occur if a protocol were used instead. That isn't how flatpak works at all. You don't use the system version, you only use the vendored version, and you do that specifically to avoid that linking problem you mentioned. Also libdecor does use the protocol so I have really no idea what you're talking about again here, sorry. >libdecor also has the potential to create other problems. Sure but the problems there would be exactly the same as they would be if you did it all in the server, so libdecor is not making it any worse. The only difference is that the code moved to the client. >If GNOME cared about what experience was good for the user, they would have cared about the fact that the Wayland compositor they shipped into production runs many games with missing window borders because of their own initiatives and sway within the Wayland ecosystem. Well I'm not sure if you saw this part in my previous part but those apps are broken according to the xdg-decoration spec. It has really nothing to do with GNOME at all. All Wayland apps need to provide fallback window borders if they want to work correctly in all situations, if they don't then that's a bug. >The user experience in GNOME is genuinely worse due to this strange insistence on moving a problem from one location to another. I don't see why that concerns you if you're not a GNOME user and you have no interest in supporting GNOME. GNOME can deal with their own problems, if that causes them to lose users then that's something only they have to care about, not you. Continued...