[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