On Mittwoch, 13. Dezember 2017 16:55:41 CET Emmanuele Bassi wrote: > - GTK supports parallel installation of different major API versions > - symbols, types, properties, and signals deprecated in a major API > version continue to exist forever (and possibly work as well) > - new major versions remove the deprecated API from the previous > major API version > - application developers port their projects between major versions > at their own leisure > > The API that gets removed in GTK+ 3.9x is deprecated in GTK+ 3.22 > beforehand.
I think most people on this list know these things already. ;-) > We are not talking about remove API inside the same major version. > > Porting applications between major versions is its own effort, just > like porting an application from Windows Vista to Windows 10, or from > macOS 10.6 to 10.12. Well, but you also know that their APIs are much more long-term stable than gtk, to a large percentage even ABI stable. >From my personal experience at least, maintaining an application on top of gtk(mm) means more effort than mainining an application on top of any other major application level framework. Unless you decide for your application to stick with gtk version x, like some projects already did for such reasons as mentioned by Sébastien. > Not every new feature or replacement will be 1:1 with deprecated API. > We did not deprecate something because we were tired of how it's > named: we deprecated it because some things should not be done any Mja, it is one thing to decide which internal things should be exposed to the API and in which way exactly. I am fine with that. Another thing is to decide on behalf of *all* application developers "you should no longer use such kind of features in your app - so we removed them". The latter is something which should clearly be avoided in a framework as much as possible. I'm logging out from this topic now, but I definitely agree with Sébastien and I also share the opinon that many gtk decisions gave me the impression that they were not made from an application developer perspective. CU Christian _______________________________________________ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
