3 ms·

I'm not going to argue about semantics but I want to be clear here: the basic definition of "backwards compatibility" is keeping the old thing working. Adding n

I'm not going to argue about semantics but I want to be clear here: the basic definition of "backwards compatibility" is keeping the old thing working. Adding new features is often at odds with this because it can break things in subtle ways. You might be able to make some small backend changes, bringing back some of the major breaking changes to widgets or to the rendering model is out of the question. If someone really wants to backport things like wayland support or emojis to GTK2, or make a shim layer to support all the old GTK2 APIs in GTK3, you could probably get people on board to take those patches somewhere. I know adding wayland support would not be simple and would probably break things as there are a lot of things in GDK2 that were direct mappings onto X11 APIs that have no analog in wayland. As the backports pile up you would have to weigh the cost of doing that versus just porting the application and getting the additional benefits of porting to a newer version. It would only be a total waste of time if there were no benefits to porting, but this is not the case. I just doubt any of the GTK4 developers are going to want to drop what they're working on now to do these things given the risk it carries combined with the fact that there are workarounds for these missing features.

badsectoracula 6y ago
> I'm not going to argue about semantics but I want to be clear here: the basic definition of "backwards compatibility" is keeping the old thing working. As i wrote a few messages above, that is the absolute minimum to call "backwards compatibility" so i'm not sure why you need to be clear since we agree on that part > Adding new features is often at odds with this because it can break things in subtle ways. You take that into consideration when you decide to add new features, it isn't like features come as demands from the gods in what and how to implement. And if you break things in subtle ways, you can fix them down the road if that is a problem - it isn't like broken code has to remain broken. > You might be able to make some small backend changes, bringing back some of the major breaking changes to widgets or to the rendering model is out of the question. The idea is to not make breaking changes to widgets in the first place. And changing the rendering model should also happen in a way that doesn't break the existing code (e.g. add a compatibility layer for custom widgets that use the previous rendering model and either make any customized widgets -e.g. buttons- to detect that they are customized and use the older rendering model in that case so they remain compatible but the new rendering model for newer code or create new widgets that use the new rendering model with an API that is as drop-in as possible so that 99% of the changes can be a search and replace in codebases). Yes, that makes things harder than simply ignoring backwards compatibility and expecting every single application that uses your library to change their own code and break any applications that cannot update to the new APIs/ABIs, but that is the price for doing backwards compatibility properly. Of course that is too late now for GTK and as i wrote previously (and later), the developers do not care about backwards compatibility anyway so i do not expect them to do anything about that when GTK5 comes around and instead they'd just expect everyone to waste time changing their working GTK4 code to use GTK5. > If someone really wants to backport things like wayland support or emojis to GTK2, or [...] this is not the case. You are missing the point, my message wasn't about what could or not be done by 3rd parties to improve GTK2 or whatever, but about what GTK developers themselves decided to do. What someone else would do is absolutely irrelevant to the topic. > I just doubt any of the GTK4 developers are going to want to drop what they're working on now to do these things given the risk it carries combined with the fact that there are workarounds for these missing features. I do not expect that to happen either, after all my first message in this submission even began with "Because the GTK developers do not care about backwards compatibility."
- cycloptic 6y ago
  I agree a compatibility layer for the rendering model could be useful but that is a separate and optional thing that someone has to write, probably someone with more of an active financial interest in old GTK versions than the GTK4 developers have. Their priority with the old versions is mostly to keep them working as-is, specifically to reduce the chance that things will break in subtle ways and then will need to be fixed later, because those issues can be hard to track down and can really harm backwards compatibility. If such a compatibility layer existed, it would not be something that needs to be part of GTK4 or hold up a GTK4 release in order for GTK2/3 applications to make use of it. It would really not have been possible to even make this kind of compatibility layer before GTK4 was stabilized. The GTK developers are just ordinary people like you or I who volunteered to work on it, if you want to change this situation then you or someone else can step up and become a GTK developer and work on this. Then you can say they care about it :) I think it is incorrect to say they don't care about backwards compatibility anyway, you seem to agree that they would meet that minimum required to claim backwards compatibility.
  - CyberRabbi 6y ago
    This is entire thread is a criticism of the GTK developers process and their decision to not invest in backwards compatibility time and time again. It’s not about what is or isn’t technically possible. (Btw it’s technically possible to innovate, have clean code, and maintain backwards compatibility without an unreasonable amount of effort.) The GTk developers aren’t ordinary people. They comprise an organization of trusted individuals and leaders. Not to mention, Many of them are employees are large companies like Red Hat and Canonical. They have resources. The likelihood of a random strangers contributions being upstreamed are low, let alone them setting project direction around backwards compatibility. Hundreds if not thousands of apps have been left behind in GTK2 and GTK1 before that. Those are all apps that could be part of the current GNOME ecosystem, now they will look like bad foreign apps. Tens of thousands of man hours completely wasted. This will kill the GNOME desktop. It’s a dead end for anyone but GNOME developers. Everyone sees it. GTK4 is just the latest demonstration of their incompetence and disregard for other developers.

badsectoracula 6y ago

> I'm not going to argue about semantics but I want to be clear here: the basic definition of "backwards compatibility" is keeping the old thing working. As i wrote a few messages above, that is the absolute minimum to call "backwards compatibility" so i'm not sure why you need to be clear since we agree on that part > Adding new features is often at odds with this because it can break things in subtle ways. You take that into consideration when you decide to add new features, it isn't like features come as demands from the gods in what and how to implement. And if you break things in subtle ways, you can fix them down the road if that is a problem - it isn't like broken code has to remain broken. > You might be able to make some small backend changes, bringing back some of the major breaking changes to widgets or to the rendering model is out of the question. The idea is to not make breaking changes to widgets in the first place. And changing the rendering model should also happen in a way that doesn't break the existing code (e.g. add a compatibility layer for custom widgets that use the previous rendering model and either make any customized widgets -e.g. buttons- to detect that they are customized and use the older rendering model in that case so they remain compatible but the new rendering model for newer code or create new widgets that use the new rendering model with an API that is as drop-in as possible so that 99% of the changes can be a search and replace in codebases). Yes, that makes things harder than simply ignoring backwards compatibility and expecting every single application that uses your library to change their own code and break any applications that cannot update to the new APIs/ABIs, but that is the price for doing backwards compatibility properly. Of course that is too late now for GTK and as i wrote previously (and later), the developers do not care about backwards compatibility anyway so i do not expect them to do anything about that when GTK5 comes around and instead they'd just expect everyone to waste time changing their working GTK4 code to use GTK5. > If someone really wants to backport things like wayland support or emojis to GTK2, or [...] this is not the case. You are missing the point, my message wasn't about what could or not be done by 3rd parties to improve GTK2 or whatever, but about what GTK developers themselves decided to do. What someone else would do is absolutely irrelevant to the topic. > I just doubt any of the GTK4 developers are going to want to drop what they're working on now to do these things given the risk it carries combined with the fact that there are workarounds for these missing features. I do not expect that to happen either, after all my first message in this submission even began with "Because the GTK developers do not care about backwards compatibility."

cycloptic 6y ago
I agree a compatibility layer for the rendering model could be useful but that is a separate and optional thing that someone has to write, probably someone with more of an active financial interest in old GTK versions than the GTK4 developers have. Their priority with the old versions is mostly to keep them working as-is, specifically to reduce the chance that things will break in subtle ways and then will need to be fixed later, because those issues can be hard to track down and can really harm backwards compatibility. If such a compatibility layer existed, it would not be something that needs to be part of GTK4 or hold up a GTK4 release in order for GTK2/3 applications to make use of it. It would really not have been possible to even make this kind of compatibility layer before GTK4 was stabilized. The GTK developers are just ordinary people like you or I who volunteered to work on it, if you want to change this situation then you or someone else can step up and become a GTK developer and work on this. Then you can say they care about it :) I think it is incorrect to say they don't care about backwards compatibility anyway, you seem to agree that they would meet that minimum required to claim backwards compatibility.
- CyberRabbi 6y ago
  This is entire thread is a criticism of the GTK developers process and their decision to not invest in backwards compatibility time and time again. It’s not about what is or isn’t technically possible. (Btw it’s technically possible to innovate, have clean code, and maintain backwards compatibility without an unreasonable amount of effort.) The GTk developers aren’t ordinary people. They comprise an organization of trusted individuals and leaders. Not to mention, Many of them are employees are large companies like Red Hat and Canonical. They have resources. The likelihood of a random strangers contributions being upstreamed are low, let alone them setting project direction around backwards compatibility. Hundreds if not thousands of apps have been left behind in GTK2 and GTK1 before that. Those are all apps that could be part of the current GNOME ecosystem, now they will look like bad foreign apps. Tens of thousands of man hours completely wasted. This will kill the GNOME desktop. It’s a dead end for anyone but GNOME developers. Everyone sees it. GTK4 is just the latest demonstration of their incompetence and disregard for other developers.