2 ms·

Sorry but you are completely missing the point, you are talking about how things could be if GTK4 did what they already have and i'm talking about how things co

Sorry but you are completely missing the point, you are talking about how things could be if GTK4 did what they already have and i'm talking about how things could be if GTK took compatibility seriously way before even GTK3 began development. Again, this isn't about what can be technically possible. As the other poster wrote, it is a criticism towards the decisions of the GTK developers. That someone else could take the code and change it, is completely, absolutely, 100% irrelevant. It has nothing to do with the comments here, they aren't about if it is technically possible to add a compatibility layer on GTK3 or GTK4 or whatever nor who will make it. It is ALL about the GTK development team's decisions, including the decisions that make a backwards compatibility harder. Also caring about backwards compatibility isn't something that can be bolted on top by a 3rd party, it is something the library has to keep in mind in the design phase. And it isn't something that can be thought as a separate component, it is something that has to be at the same level as everything else. Expecting that it is something that "shouldn't hold up a GTK release" is a completely wrong way of thinking about backwards compatibility - a project that cares about being backwards compatible considers it as important as any other change (new features, bug fixes, etc) and not something to be an afterthought. > 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 :) Sure, they may be (i do not know) and they have all the rights to ignore backwards compatibility - it isn't like i'm paying them to work on their library or be in a position to make any demands out of them. But that doesn't mean i wont say they do not care about backwards compatibility. > I think it is incorrect to say they don't care about backwards compatibility anyway, It is absolutely correct because this is what they have repeatedly shown. > you seem to agree that they would meet that minimum required to claim backwards compatibility. No, i do agree with that, what i agreed with is the definition that keeping code running is the absolute minimum one would do to provide backwards compatibility, but i never claimed that the GTK developers care about it. These are two different things: one can not care about backwards compatibility, yet still provide that minimum amount for it for practical and strategic reasons to entice people move to the next version.

cycloptic 6y ago
Sorry I still don't see the point. We could speculate how things could have turned out differently if they made different decisions 20 years ago, but that would just be it: speculation. If you have some better way to design it that you think could preserve perfect backwards compatibility while allowing the same pace of feature development, you should let them know. Because AFAIK both of those are at odds, no developer can realistically spend time on both for an indefinite period of time, and if there are no new features that anyone wants then backwards compatibility is irrelevant anyway. >Expecting that it is something that "shouldn't hold up a GTK release" is a completely wrong way of thinking about backwards compatibility Why? Once you decide to refactor an API you have to maintain an extra piece to translate the old to the new, there is no way around that. Developers can spend time before the release working on this translation piece alongside the new features or they can just release it now so people can test the new API before deciding to invest in developing that. For an open source project I can't see how the first option really makes sense, and if your argument is that they should have been developing it the whole time, that is essentially what they were doing for the entirety of the GTK3 development cycle. That is being generous in assuming that it's even possible to do this, sometimes a design is so flawed that you can't even make it work at all with the new stuff. At some point you have decide to cut deprecated APIs or you are left with an infinitely growing pile of technical debt. I referred to this elsewhere, but old GTK1/2 applications that use raw unscaled pixel buffers are an example: there is no backwards compatibility that is going to work here that makes them function correctly with high dpi. It simply cannot work if the application is hardcoded to use an old API that has no concept of dpi or scale and assumes a pixel is always the same size. (Maybe someone can cheat with AI upscaling algorithms but those are usually pretty slow :) I guess to put it another way: I don't see any way that GTK4 could have been designed differently to do something like make it easier to compile GTK1 apps against it while reaping all the benefits of GTK4. If somebody wants to make a GTK1 shim for GTK4 that translates GTK1 API calls into GTK4 API calls, they can go do it now, it would probably be a pain and it's probably not going to magically get you all the new benefits that would come from just porting the application to GTK4 and refactoring to use its new techniques along the way.

cycloptic 6y ago

Sorry I still don't see the point. We could speculate how things could have turned out differently if they made different decisions 20 years ago, but that would just be it: speculation. If you have some better way to design it that you think could preserve perfect backwards compatibility while allowing the same pace of feature development, you should let them know. Because AFAIK both of those are at odds, no developer can realistically spend time on both for an indefinite period of time, and if there are no new features that anyone wants then backwards compatibility is irrelevant anyway. >Expecting that it is something that "shouldn't hold up a GTK release" is a completely wrong way of thinking about backwards compatibility Why? Once you decide to refactor an API you have to maintain an extra piece to translate the old to the new, there is no way around that. Developers can spend time before the release working on this translation piece alongside the new features or they can just release it now so people can test the new API before deciding to invest in developing that. For an open source project I can't see how the first option really makes sense, and if your argument is that they should have been developing it the whole time, that is essentially what they were doing for the entirety of the GTK3 development cycle. That is being generous in assuming that it's even possible to do this, sometimes a design is so flawed that you can't even make it work at all with the new stuff. At some point you have decide to cut deprecated APIs or you are left with an infinitely growing pile of technical debt. I referred to this elsewhere, but old GTK1/2 applications that use raw unscaled pixel buffers are an example: there is no backwards compatibility that is going to work here that makes them function correctly with high dpi. It simply cannot work if the application is hardcoded to use an old API that has no concept of dpi or scale and assumes a pixel is always the same size. (Maybe someone can cheat with AI upscaling algorithms but those are usually pretty slow :) I guess to put it another way: I don't see any way that GTK4 could have been designed differently to do something like make it easier to compile GTK1 apps against it while reaping all the benefits of GTK4. If somebody wants to make a GTK1 shim for GTK4 that translates GTK1 API calls into GTK4 API calls, they can go do it now, it would probably be a pain and it's probably not going to magically get you all the new benefits that would come from just porting the application to GTK4 and refactoring to use its new techniques along the way.