Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

>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....



Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: