| >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... |
Sure, but if you don't use a toolkit then you need to take care of the missing pieces on your platform, in the case of Wayland one of those missing pieces is window borders. If you're a toolkit developer and you can't implement window borders, then I would suggest not advertising your toolkit as having complete support for Wayland.
>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.
I'm sorry if this seems rude but both your opinion and my opinion don't matter and I don't care how you feel about this. That's nothing personal towards you. We're just two people having an informal conversation, it's just not helpful for us to look at it like we're trying to sway each other's opinions, so don't feel like you have to convince me of something or rebut my opinions. If you feel you don't want to support a certain type of decorations then that's perfectly fine, I'm happy for you to carry on doing that. But the technical reality of the situation and what that means for the challenges you may face is a different discussion from what you or I feel, and clearing up the technical stuff is all I'm interested to discuss.
If you have some other technical things to present then please do that, otherwise you're right that there is nothing more to discuss here. I'm only typing here to correct some misconceptions that I saw you had about the whole situation with libdecor. I find that most people who are upset about the situation don't really understand it fully or missed some key piece of information. I usually try not to do it point-by-point but it's really hard when you list a lot of points. However it does seem that a lot of your statements are stemming from a few initial misconceptions, so I can summarize that if you want.