4 ms·

>retain GtkHBox and simply implement it in terms of GtkBox with a defaulted "orientation" to horizontal. I'm sorry, I understand your frustration but to me thi

>retain GtkHBox and simply implement it in terms of GtkBox with a defaulted "orientation" to horizontal. I'm sorry, I understand your frustration but to me this is a terrible example and kind of makes the rest of your post look like complaining about a non-issue. This is exactly how it's already implemented in GTK 3. GtkHBox was deprecated there and slated for eventual removal, then it got removed in GTK 4 because the whole point of it is an API break and removal of deprecated functions. If this bothers you, you can keep using GTK 3 which is now considered feature-complete. The situation with GTK 2 was the same, you could keep on using it if you didn't want to bother updating your application.

rleigh 6y ago
Wow, that response demonstrates exactly what is wrong with this library and its developers. "You can carry on using the old version" is a real cop-out which does not address the substance of the complaint in any way whatsoever. Yes, I know it's being removed in GTK+4. You didn't have to remove it. You chose to. And to hell with the consequences. You could have kept it pretty much indefinitely with near zero maintenance overhead if you cared about compatibility and the extent to which that core functionality was used. I am always surprised at how much time gets wasted on trivia, and yet a simple maintenance issue like this is too difficult despite requiring much less effort.
- cycloptic 6y ago
  I'm not a GTK developer so please spare me the shooting of the messenger. All I did was read their documentation. From what I've seen there are very few paid developers actually working on GTK. Everyone else is volunteers and none of them are interested in maintaining deprecated APIs for any protracted amount of time. Even with the removal of a lot of deprecated functions in GTK 4, there is still a ton of untested code sitting around that nobody really maintains. You're welcome to write tests for these and maintain an external compatibility layer yourself if you want, but it makes no sense to expect other volunteer developers to do this for you when the old versions are considered stable.
  - rleigh 6y ago
    > "Everyone else is volunteers and none of them are interested in maintaining deprecated APIs" This is a complete cop-out. It's maintained by several RedHat employees as part of their duties, and a handful of volunteers. Every software project on the planet, including commercial ones, is maintained with limited resources. The amount of development and maintenance which is possible is constrained by the available developer hours, and work is budgeted based on that. The cost/benefit of maintaining the compatibility code is so low that it's not even worth the effort to remove it. The time taken to drop it was likely on a par with the time to retain it. It was already written. But the cost imposed on all their userbase after removing it is absolutely huge. And it means that an application can't target old and new versions due to the break. That wreaks havoc with support lifetimes and imposes thousands of developer-hours of effort for porting. Lots of effort... just to get back to where you were. Unjustifiable. I could understand if there was a huge benefit to be gained. But there isn't. And when you look at what they do spend their time on, so much is wasted on other activities that justifying its removal based upon developer resources wears a little thin. It's a weak justification which ultimately boils down to just wanting to, and completely ignoring the actual users of the library.
    - cycloptic 6y ago
      If the cost/benefit is so low then you do it. I'm completely 100% serious about this, I assume you have some customers lined up who are willing to pay for this so just take the money and don't worry about what anyone else does. Make it as an external library so you don't have to spend time convincing upstream to merge and maintain it. None of the existing volunteers are willing to do this work, and the paid developers get paid to work on what Red Hat customers pay them to work on, which evidently is not related to maintaining legacy applications at all. If they want to leave money on the table, that's their problem. There is nothing wrong about what you're saying but it's mostly hot air, you're preaching to the choir here.
  - deleted 6y ago
    [deleted]
- chris_wot 6y ago
  Deprecated means “if you use this, on your own heads be it”.
  - rleigh 6y ago
    Deprecation does not imply removal in the short-term. Java has deprecated many things which will never be removed, because they care about compatibility. Just because there's a newer way to do something does not mean the old way must be removed as soon as possible. If it was very high maintenance and it prevented the addition of new functionality, this might be justified. But that's not the case. It's completely gratuitous. The GTK+ removals are akin to removing "strlen()" from the C library because a better "strlengh()" was added in the meantime. Compatibility matters. And well-maintained projects balance that with the addition of new features.
    - chris_wot 6y ago
      Perhaps there should be a raft of functions in the C library that are deprecated and removed.
      - rleigh 6y ago
        Deprecated, perhaps, should suitable replacements be standardised. Removed, absolutely not. It cannot be overstated just how terrible compatibility breaks are. C is nearly 50 years old, and all of its standard functions are thoroughly entrenched, despite their numerous known defects. It took long enough to eliminate gets(), and that was broken from inception. In almost all cases, removal is not the best solution. Supplementing with a safer or better alternative to supersede the original, by all means. But deliberate breakage causes nothing but pain all around. In the case of GTK+, it's nearly 25 years old. These is a legacy of thousands of applications, large and small, which have invested hundreds of thousands of developer-hours in it. Obsoleting things might save the GTK+ developers a little extra effort (though I doubt this), but it imposes several orders of magnitude more work upon the worldwise developer base tied to GTK+, which could be avoided entirely without holding back progress.

rleigh 6y ago

Wow, that response demonstrates exactly what is wrong with this library and its developers. "You can carry on using the old version" is a real cop-out which does not address the substance of the complaint in any way whatsoever. Yes, I know it's being removed in GTK+4. You didn't have to remove it. You chose to. And to hell with the consequences. You could have kept it pretty much indefinitely with near zero maintenance overhead if you cared about compatibility and the extent to which that core functionality was used. I am always surprised at how much time gets wasted on trivia, and yet a simple maintenance issue like this is too difficult despite requiring much less effort.

cycloptic 6y ago
I'm not a GTK developer so please spare me the shooting of the messenger. All I did was read their documentation. From what I've seen there are very few paid developers actually working on GTK. Everyone else is volunteers and none of them are interested in maintaining deprecated APIs for any protracted amount of time. Even with the removal of a lot of deprecated functions in GTK 4, there is still a ton of untested code sitting around that nobody really maintains. You're welcome to write tests for these and maintain an external compatibility layer yourself if you want, but it makes no sense to expect other volunteer developers to do this for you when the old versions are considered stable.
- rleigh 6y ago
  > "Everyone else is volunteers and none of them are interested in maintaining deprecated APIs" This is a complete cop-out. It's maintained by several RedHat employees as part of their duties, and a handful of volunteers. Every software project on the planet, including commercial ones, is maintained with limited resources. The amount of development and maintenance which is possible is constrained by the available developer hours, and work is budgeted based on that. The cost/benefit of maintaining the compatibility code is so low that it's not even worth the effort to remove it. The time taken to drop it was likely on a par with the time to retain it. It was already written. But the cost imposed on all their userbase after removing it is absolutely huge. And it means that an application can't target old and new versions due to the break. That wreaks havoc with support lifetimes and imposes thousands of developer-hours of effort for porting. Lots of effort... just to get back to where you were. Unjustifiable. I could understand if there was a huge benefit to be gained. But there isn't. And when you look at what they do spend their time on, so much is wasted on other activities that justifying its removal based upon developer resources wears a little thin. It's a weak justification which ultimately boils down to just wanting to, and completely ignoring the actual users of the library.
  - cycloptic 6y ago
    If the cost/benefit is so low then you do it. I'm completely 100% serious about this, I assume you have some customers lined up who are willing to pay for this so just take the money and don't worry about what anyone else does. Make it as an external library so you don't have to spend time convincing upstream to merge and maintain it. None of the existing volunteers are willing to do this work, and the paid developers get paid to work on what Red Hat customers pay them to work on, which evidently is not related to maintaining legacy applications at all. If they want to leave money on the table, that's their problem. There is nothing wrong about what you're saying but it's mostly hot air, you're preaching to the choir here.
- deleted 6y ago
  [deleted]
chris_wot 6y ago
Deprecated means “if you use this, on your own heads be it”.
- rleigh 6y ago
  Deprecation does not imply removal in the short-term. Java has deprecated many things which will never be removed, because they care about compatibility. Just because there's a newer way to do something does not mean the old way must be removed as soon as possible. If it was very high maintenance and it prevented the addition of new functionality, this might be justified. But that's not the case. It's completely gratuitous. The GTK+ removals are akin to removing "strlen()" from the C library because a better "strlengh()" was added in the meantime. Compatibility matters. And well-maintained projects balance that with the addition of new features.
  - chris_wot 6y ago
    Perhaps there should be a raft of functions in the C library that are deprecated and removed.
    - rleigh 6y ago
      Deprecated, perhaps, should suitable replacements be standardised. Removed, absolutely not. It cannot be overstated just how terrible compatibility breaks are. C is nearly 50 years old, and all of its standard functions are thoroughly entrenched, despite their numerous known defects. It took long enough to eliminate gets(), and that was broken from inception. In almost all cases, removal is not the best solution. Supplementing with a safer or better alternative to supersede the original, by all means. But deliberate breakage causes nothing but pain all around. In the case of GTK+, it's nearly 25 years old. These is a legacy of thousands of applications, large and small, which have invested hundreds of thousands of developer-hours in it. Obsoleting things might save the GTK+ developers a little extra effort (though I doubt this), but it imposes several orders of magnitude more work upon the worldwise developer base tied to GTK+, which could be avoided entirely without holding back progress.