[prev in list] [next in list] [prev in thread] [next in thread] 

List:       gtk-devel
Subject:    Re: First deprecate APIs and then remove them in the next major version
From:       Emmanuele Bassi <ebassi () gmail ! com>
Date:       2017-12-14 20:34:51
Message-ID: CALnHYQH+mOc8pP4b_W01pCDOPn=+5xMsNHmGLoHguR7K8C-pWw () mail ! gmail ! com
[Download RAW message or body]

On 14 December 2017 at 18:42, Sébastien Wilmet <swilmet@gnome.org> wrote:
> On Wed, Dec 13, 2017 at 04:55:41PM +0000, Emmanuele Bassi wrote:
>> The API that gets removed in GTK+ 3.9x is deprecated in GTK+ 3.22 beforehand.
>
> No, that's not true.
>
> 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.

This is also why we could not do this during the 3.x API cycle,
without incurring into a lot of regressions or potential breakage.

> I think Benjamin has done a great work with the new implementation. Just
> a little problem: it's what I call a "direct API break", applications or
> higher-level libraries will need to be ported from GTK+ 3.92 to 3.94
> with a big API delta, so it will result in one huge commit/branch
> untestable until all the code is ported [1].

That's what we said would happen during the 9x development cycle: no
API stability between 9x and 9x+2. We were very much upfront about the
API stability.

> It's of course much worse
> if porting directly from 3.22 to 4.0.

And we understand that. Doing this work in 5 years, for GTK+ 5.0,
would not have been any easier for anybody.

> [1] What I would recommend is to copy custom widgets/containers (if they
> are self-contained) out-of-tree, and port them individually, with a
> small GUI test program for each, so that they can be tested outside the
> whole application.

That would not help at all for the GtkClipboard case, and that would
not help with the new rendering API.

I'm sorry about the pain in porting, but this is what 2.5 years of
development are for.

Ciao,
 Emmanuele.

-- 
https://www.bassi.io
[@] ebassi [@gmail.com]
_______________________________________________
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

[prev in list] [next in list] [prev in thread] [next in thread]