On Thu, Dec 14, 2017 at 08:34:51PM +0000, Emmanuele Bassi wrote: > On 14 December 2017 at 18:42, Sébastien Wilmet <swil...@gnome.org> wrote: > > A recent example: > > https://git.gnome.org/browse/gtk+/commit/?id=2d5c82b4ecbe6ff534a1b9476080e409742daa39 > > "gtk: Remove GtkClipboard" > > > > The clipboard is now implemented in GDK. GtkClipboard is not deprecated > > in GTK+ 3.22, and the new API is not available in GDK 3.22. > > The new API just landed; and, yes: it's hard to deprecate the API in > this case, given that the new API has been moved down one level in the > hierarchy.
GDK, GSK and GTK are now part of the same *.so library. If GtkClipboard still worked fine just before the commit that removed it, it would have been possible to first deprecate GtkClipboard and then removing it in 3.9x+2 (see my comment below). Of course if GtkClipboard didn't work anymore, then it needed to be removed. Or maybe it was possible to port GtkClipboard to the new GDK API, but this would have been more work for the GTK developers. It all depends if you want to provide a smooth experience to port apps. > Doing this work in 5 years, for GTK+ 5.0, > would not have been any easier for anybody. I don't understand why you say that. Each semi-stable 3.9x version can be seen as a new major version, since it's possible to break the API. So an API can be marked as deprecated in 3.92 and then removed in 3.94. Instead of doing a direct API break. This would make it easier to port applications. -- Sébastien _______________________________________________ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
