[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-16 19:17:11
Message-ID: CAFwd_vDV_hdj2iKtgi-0zJT2VTeJ4iiVV-9FX9kPuH50NgXUgA () mail ! gmail ! com
[Download RAW message or body]
[Attachment #2 (multipart/alternative)]
On Sat, Dec 16, 2017 at 9:12 AM, Christian Schoenebeck <
schoenebeck@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.
[Attachment #5 (text/html)]
<div dir="ltr">On Sat, Dec 16, 2017 at 9:12 AM, Christian Schoenebeck <span \
dir="ltr"><<a href="mailto:schoenebeck@linuxsampler.org" \
target="_blank">schoenebeck@linuxsampler.org</a>></span> wrote:<br><div \
class="gmail_extra"><div class="gmail_quote"><span \
class="gmail-"></span><br><span class="gmail-"></span><blockquote \
class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid \
rgb(204,204,204);padding-left:1ex"><span class="gmail-"> ><br>
> With cooperation and compatibility layers in GTK, GTK would move \
forward<br> > less quickly, but it would maybe yield a better outcome \
globally when<br> > taking into account higher-level libraries and \
applications.<br> <br>
</span>This is always the common argument "retaining old APIs means \
more work". But<br> if you look at what APIs had been removed in gtk \
(and glib and co) in the<br> past, most of them could have been preserved \
with no or little effort on<br> library level.<br>
<br>
I mean to me it looks like nobody even considered in the past to keep old \
APIs<br> at all. Currently it is just a common rule "ok, we are now on \
the next major<br> version branch, we are now safe to do whatever we want \
to do, so let's start<br> removing everything we don't like \
anymore".<br></blockquote><div><br></div><div>Maybe give a concrete \
example of an api that we could have 'preserved with no \
effort"</div><div>and yet removed out of folly ? I would be \
interested.<br></div><div> <br></div><blockquote class="gmail_quote" \
style="margin:0px 0px 0px 0.8ex;border-left:1px solid \
rgb(204,204,204);padding-left:1ex"> Addressing major library changes on \
application level often means *much* more<br> effort, because as \
application you don't necessarily have access to library<br> internal \
things nor can you make certain presumptions. Plus not only one gtk<br> app \
project has to do that gtk version compatibility work, all gtk app<br> \
projects need to do them. If you calculate how many man hours are wasted \
on<br> all these applications, just for retaining compatiblity with the \
latest major<br> gtk version, then you probably might see that the trash \
can decisions are<br> currently made far too easily on library \
level.<br></blockquote><div><br></div><div>To me this reads like a \
misunderstanding.</div><div><br></div><div>Moving an application from GTK3 \
to GTK4 means porting work. But you do it only once,</div><div>and you \
don't retain GTK3 compatibility. At least, that is not what the GTK+ \
team</div><div>recommends you should do.<br></div><div><br></div><div>If \
you want to stick with GTK3, you are more than welcome to do so for years \
to come.<br></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]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic