On Sat, Dec 16, 2017 at 9:12 AM, Christian Schoenebeck < schoeneb...@linuxsampler.org> wrote:
> > > With cooperation and compatibility layers in GTK, GTK would move forward > > less quickly, but it would maybe yield a better outcome globally when > > taking into account higher-level libraries and applications. > > This is always the common argument "retaining old APIs means more work". > But > if you look at what APIs had been removed in gtk (and glib and co) in the > past, most of them could have been preserved with no or little effort on > library level. > > I mean to me it looks like nobody even considered in the past to keep old > APIs > at all. Currently it is just a common rule "ok, we are now on the next > major > version branch, we are now safe to do whatever we want to do, so let's > start > removing everything we don't like anymore". > Maybe give a concrete example of an api that we could have 'preserved with no effort" and yet removed out of folly ? I would be interested. > Addressing major library changes on application level often means *much* > more > effort, because as application you don't necessarily have access to library > internal things nor can you make certain presumptions. Plus not only one > gtk > app project has to do that gtk version compatibility work, all gtk app > projects need to do them. If you calculate how many man hours are wasted > on > all these applications, just for retaining compatiblity with the latest > major > gtk version, then you probably might see that the trash can decisions are > currently made far too easily on library level. > To me this reads like a misunderstanding. Moving an application from GTK3 to GTK4 means porting work. But you do it only once, and you don't retain GTK3 compatibility. At least, that is not what the GTK+ team recommends you should do. If you want to stick with GTK3, you are more than welcome to do so for years to come.
_______________________________________________ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list