[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:       Matthias Clasen <matthias.clasen () gmail ! com>
Date:       2017-12-15 16:10:46
Message-ID: CAFwd_vCD2noBzKtsAFqTqyVGaPw=k9Nxfbh5knTaavQj0z7SqA () mail ! gmail ! com
[Download RAW message or body]

[Attachment #2 (multipart/alternative)]


On Thu, Dec 14, 2017 at 4:41 PM, S=C3=A9bastien Wilmet <swilmet@gnome.org> =
wrote:

>
>
> 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.
>
>
I know this may sound harsh, but: If you want things to work differently,
send patches.
Patches to the migration guide are welcome too.

The bulk of the work done on GTK4 so far has been done by 3 or 4 people,
only one of
which gets payed to work fulltime on GTK+.

Maintaining compatibility layers costs and constantly gets in the way of
large-scale
refactorings like the ones that are happening in gtk 3.9x now.

Note that we haven't really asked application developers to port to the
current 3.9x releases
yet, because they are still in flux.

[Attachment #5 (text/html)]

<div dir="ltr">On Thu, Dec 14, 2017 at 4:41 PM, Sébastien Wilmet <span \
dir="ltr">&lt;<a href="mailto:swilmet@gnome.org" \
target="_blank">swilmet@gnome.org</a>&gt;</span> wrote:<br><div \
class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" \
style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span \
class=""><br> <br>
</span>GDK, GSK and GTK are now part of the same *.so library. If GtkClipboard<br>
still worked fine just before the commit that removed it, it would have<br>
been possible to first deprecate GtkClipboard and then removing it in<br>
3.9x+2 (see my comment below).<br>
<br>
Of course if GtkClipboard didn&#39;t work anymore, then it needed to be<br>
removed. Or maybe it was possible to port GtkClipboard to the new GDK<br>
API, but this would have been more work for the GTK developers. It all<br>
depends if you want to provide a smooth experience to port apps.<br>
<span class=""></span><br></blockquote><div><br></div><div>I know this may sound \
harsh, but: If you want things to work differently, send patches.</div><div>Patches \
to the migration guide are welcome too.<br></div><div><br></div><div>The bulk of the \
work done on GTK4 so far has been done by 3 or 4 people, only one of</div><div>which \
gets payed to work fulltime on GTK+.</div><div><br></div><div>Maintaining \
compatibility layers costs and constantly gets in the way of \
large-scale</div><div>refactorings like the ones that are happening in gtk 3.9x \
now.</div><div><br></div><div>Note that we haven&#39;t really asked application \
developers to port to the current 3.9x releases</div><div>yet, because they are still \
in flux.<br></div><div>  </div></div></div></div>



_______________________________________________
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]