3 ms·

They deprecated functionality that no longer fit GNOME's workflow even if it is when it's still needed on other desktops and operating systems (see systray icon

by guug 7y ago

They deprecated functionality that no longer fit GNOME's workflow even if it is when it's still needed on other desktops and operating systems (see systray icons[1]). Their developers stated on more than one occasion that GTK is a GNOME-first toolkit. Relying on GTK to be a cross-platform GUI toolkit is very risky given its current direction. [1]: https://developer.gnome.org/gtk3/stable/GtkStatusIcon.html https://developer.gnome.org/gtk3/stable/GtkStatusIcon.html

cycloptic 7y ago
I don't see how that follows and I think your explanation is a bit mixed up. That functionality was deprecated precisely because it WASN'T cross-platform, and there was no way to make it work correctly on all platforms because of how much it was tied to legacy behavior. It never even worked on Mac, and it won't work now on Wayland either, so that's why it's got deprecated and removed. >Their developers stated on more than one occasion that GTK is a GNOME-first toolkit. I have not heard this. I've actually seen great pains being taken to preserve Windows and Mac support in GTK4. For the record I actually think removing something because GNOME doesn't support it would be very valid and wouldn't make them a GNOME-first toolkit. A proper cross-platform toolkit would consider all the supported platforms equally and would support things that can work correctly across all of them, and in this case GNOME happens to be one of those platforms. Remember that they've also deprecated and removed things in the past that didn't work on Windows, such as all the X11-centric stuff that was present in GTK1 and GTK2.
- 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 guug 7y ago

cycloptic 7y ago

I don't see how that follows and I think your explanation is a bit mixed up. That functionality was deprecated precisely because it WASN'T cross-platform, and there was no way to make it work correctly on all platforms because of how much it was tied to legacy behavior. It never even worked on Mac, and it won't work now on Wayland either, so that's why it's got deprecated and removed. >Their developers stated on more than one occasion that GTK is a GNOME-first toolkit. I have not heard this. I've actually seen great pains being taken to preserve Windows and Mac support in GTK4. For the record I actually think removing something because GNOME doesn't support it would be very valid and wouldn't make them a GNOME-first toolkit. A proper cross-platform toolkit would consider all the supported platforms equally and would support things that can work correctly across all of them, and in this case GNOME happens to be one of those platforms. Remember that they've also deprecated and removed things in the past that didn't work on Windows, such as all the X11-centric stuff that was present in GTK1 and GTK2.

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