4 ms·

> functionality was deprecated precisely because it WASN'T cross-platform No, they've deprecated and removed far, far more than that. They've obsoleted and dr

by rleigh 7y ago

> functionality was deprecated precisely because it WASN'T cross-platform No, they've deprecated and removed far, far more than that. They've obsoleted and dropped fundamental containers and widgets which have been present right from the 1.x days. These changes represent hard compatibility breaks, each and every one of them. As an application developer, these are not improvements, but very costly. And they even broke compatibility with their UI file formats, with no upgrade path. Upgrading now requires hand-editing huge piles of XML. They could have written some simple XSLT transforms to provide an upgrade path, but they didn't. Or you have to hand-edit all of your sources. Either way, it's painful and with zero added value. I don't expect a competently-maintained library to indulge in such huge breaking changes without a really, really good reason. The old functionality could have been retained, implemented entirely in terms of the new, but they just had to rip it all out for the sake of it. That's not maintenance with end developers in mind. It's a huge "screw you" to their actual userbase: application developers.

cycloptic 7y ago
>These changes represent hard compatibility breaks, each and every one of them. As an application developer, these are not improvements, but very costly. >The old functionality could have been retained, implemented entirely in terms of the new, but they just had to rip it all out for the sake of it. That's not maintenance with end developers in mind. I see these kinds of things being said all the time but at the end of the day, nobody seems to want to pick up the slack and start maintaining all those legacy widgets for eternity. There is a maintenance cost there too and the upstream developers don't want to foot the bill, and neither do you, so stuff gets dropped on the floor. If you don't want to deal with this then you use flatpak/snap and you pin your application to a specific toolkit version forever. Do you have any better proposals? Do we as an industry have any better proposals besides throwing money at the problem? Because I assure you GTK is not the first (or last) library in existence to break ABI. >They could have written some simple XSLT transforms to provide an upgrade path, but they didn't. They did. In GTK4 there is an automated tool to update the XML. It doesn't really work perfectly right now, but GTK4 is still pre-alpha. https://developer.gnome.org/gtk4/stable/ch31s02.html#id-1.6.4.4.3 https://developer.gnome.org/gtk4/stable/ch31s02.html#id-1.6....

by rleigh 7y ago

cycloptic 7y ago

>These changes represent hard compatibility breaks, each and every one of them. As an application developer, these are not improvements, but very costly. >The old functionality could have been retained, implemented entirely in terms of the new, but they just had to rip it all out for the sake of it. That's not maintenance with end developers in mind. I see these kinds of things being said all the time but at the end of the day, nobody seems to want to pick up the slack and start maintaining all those legacy widgets for eternity. There is a maintenance cost there too and the upstream developers don't want to foot the bill, and neither do you, so stuff gets dropped on the floor. If you don't want to deal with this then you use flatpak/snap and you pin your application to a specific toolkit version forever. Do you have any better proposals? Do we as an industry have any better proposals besides throwing money at the problem? Because I assure you GTK is not the first (or last) library in existence to break ABI. >They could have written some simple XSLT transforms to provide an upgrade path, but they didn't. They did. In GTK4 there is an automated tool to update the XML. It doesn't really work perfectly right now, but GTK4 is still pre-alpha. https://developer.gnome.org/gtk4/stable/ch31s02.html#id-1.6.4.4.3 https://developer.gnome.org/gtk4/stable/ch31s02.html#id-1.6....