2 ms·

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

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.
- cycloptic 6y ago
  >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. Please don't use this type of hyperbole, I've heard this type of thing often in various contexts, and while it may be fun to say, it's inaccurate and it's thoroughly unproductive in getting the actual issues solved. What you view as incompetence and disregard is more accurately described as "lack of time." IIRC there are only really 2-3 people working full time on GTK, and most of their efforts are focused on getting new releases out the door. It's not as many resources as it may seem from the outside and they don't have time to do everything that people want. They depend on volunteer contributors to handle the long tail of issues and edge cases that come up with older applications. If you'd like to improve GTK2 and GTK1 applications, please find a way to contribute and help out! I can help to point you in a direction if you want. (I don't think it's really much of a big deal if older applications look weird, the main concern with them is usually that they don't break. From this angle, GTK1 and GTK2 apps are not being left behind, they work perfectly fine even on a modern system) I'll warn you though, it's not trivial to get a legacy app to look and act native on a modern platform. If you really want to do a good job at it, you have to manually redesign each of the apps individually and it gets time-consuming. I personally think it would be great if XFCE/Mate/Budgie/Cinnamon/etc had the resources to pay more full time developers to contribute upstream and collaborate more with the GNOME people, but we are not there yet unfortunately.
  - ldarby 6y ago
    > GTK1 and GTK2 apps are not being left behind, they work perfectly fine even on a modern system Wrong, GTK 1 was removed from Debian over 10 years ago: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=520441 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=520441
    - cycloptic 6y ago
      That doesn't mean it doesn't work. The package was removed because it wasn't getting security updates, however I see no reason why it wouldn't work if you gather all the dependencies and recompile it.
badsectoracula 6y ago
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.

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.

cycloptic 6y ago
>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. Please don't use this type of hyperbole, I've heard this type of thing often in various contexts, and while it may be fun to say, it's inaccurate and it's thoroughly unproductive in getting the actual issues solved. What you view as incompetence and disregard is more accurately described as "lack of time." IIRC there are only really 2-3 people working full time on GTK, and most of their efforts are focused on getting new releases out the door. It's not as many resources as it may seem from the outside and they don't have time to do everything that people want. They depend on volunteer contributors to handle the long tail of issues and edge cases that come up with older applications. If you'd like to improve GTK2 and GTK1 applications, please find a way to contribute and help out! I can help to point you in a direction if you want. (I don't think it's really much of a big deal if older applications look weird, the main concern with them is usually that they don't break. From this angle, GTK1 and GTK2 apps are not being left behind, they work perfectly fine even on a modern system) I'll warn you though, it's not trivial to get a legacy app to look and act native on a modern platform. If you really want to do a good job at it, you have to manually redesign each of the apps individually and it gets time-consuming. I personally think it would be great if XFCE/Mate/Budgie/Cinnamon/etc had the resources to pay more full time developers to contribute upstream and collaborate more with the GNOME people, but we are not there yet unfortunately.
- ldarby 6y ago
  > GTK1 and GTK2 apps are not being left behind, they work perfectly fine even on a modern system Wrong, GTK 1 was removed from Debian over 10 years ago: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=520441 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=520441
  - cycloptic 6y ago
    That doesn't mean it doesn't work. The package was removed because it wasn't getting security updates, however I see no reason why it wouldn't work if you gather all the dependencies and recompile it.

badsectoracula 6y ago

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.