First deprecate APIs and then remove them in the next major version

classic Classic list List threaded Threaded
30 messages Options
12
Reply | Threaded
Open this post in threaded view
|

First deprecate APIs and then remove them in the next major version

Sébastien Wilmet-2
Hi,

I'm a bit worried about how GTK+ 4 is developed. It seems that there
will be a lot of API breaks that will require to adapt the code at once.

Ideally, a new major version of a library should only remove deprecated
APIs. It's how a library should be developed, in case the developers
want to get rid of old APIs: 1. New APIs are added. 2. Old APIs are
marked as deprecated (but still work). 3. In the next major version,
deprecated APIs are removed.

Why is it a good practice to follow that approach? Because developers
using the library can port their code to the new APIs *incrementally*.
The deprecated APIs still work, so the code can be ported to the new
APIs, one step at a time, by writing small and testable commits (for
each commit, the code can be compiled, running the unit tests, testing
the GUI, etc). Not with one huge commit/branch, untestable until all the
code is ported.

It is more work for the library developers to keep the deprecated APIs
still working, but it provides a much smoother experience for all the
developers using the library (and in case of GTK+, there are a lot of
users). Can I remind you that most of the biggest GTK+ apps are still
using GTK+ 2? MonoDevelop, GIMP, Ardour, …

With the new model of GTK+ development, each stable GTK+ 3.9x version
can be seen as a new major version, so that developers can port their
code to 3.90, then 3.92, etc (if those versions are in a sufficiently
usable state). But currently, with how those versions are developed,
it'll be quite hard to port the code, the same as the GTK+ 2 -> 3
transition, because there are direct API breaks instead of just removing
deprecated APIs.

So, that's it, I think when GTK+ 4.0 will be released, if it is still
developed in the same way, developers will have a really bad surprise
when trying to port their code. At least 2 years worth of direct API
breaks… GTK+ 4 will probably be awesome for writing new applications,
but it'll probably be a different story for developers wanting to port
their code from GTK+ 3.

GTK+ 3 was criticized for being a bit unstable. But that was not the
root of the problem IMHO, the root of the problem is that there are
direct API breaks (and for GTK+ 3, the CSS was not sufficiently
advertised as having an unstable API; it's fine to have unstable APIs in
a library, but there must be big warnings in the documentation).

My 2 cents,
Sébastien
_______________________________________________
gtk-devel-list mailing list
[hidden email]
https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Reply | Threaded
Open this post in threaded view
|

Re: First deprecate APIs and then remove them in the next major version

Emmanuele Bassi
On 13 December 2017 at 12:05, Sébastien Wilmet <[hidden email]> wrote:

> Ideally, a new major version of a library should only remove deprecated APIs.

I'm having major flashbacks from the same discussions we had at Gran
Canaria, when we planned 3.0 — with people asking for releasing 3.0
only with sealed data structures and without deprecated API.

The short answer is: that's not how library development works, unless
you have a small enough library whose API is inconsequential, or it's
used only by a handful of projects. GTK is neither.

If we just removed deprecated API without adding any new feature,
there would be no incentive whatsoever to port applications to a new
major version, which will result in an untested API that we cannot
change until the next major release cycle.

That's why we released the 9x snapshots; to give us, and application
developers, time to iterate over the API.

The problem is that we're trying to fix almost two decaded of hacks
and cruft piled on top of each other, and any new feature comes with
its own set of removals.

> So, that's it, I think when GTK+ 4.0 will be released, if it is still
> developed in the same way, developers will have a really bad surprise
> when trying to port their code.

The reason why we're doing the 9x snapshots — the reason we change the
whole release management process and model — is because we will *not*
be developing 4.x (and 5.x, and 6.x) the same way we developed 3.x.

The 9x snapshots are the first cycles of 3.x, writ large. We give up
API compatibility during that period in order to have a firmer n.0
release, and later minor cycles, until we open the tree for the n+1
development.

Yes: the delta between 3.x and 4.x is going to be large — at least, if
you're implementing widgets. It's not something we expect this to
happen with every major release; we don't really expect to change the
way we render everything, or to change the input subsystem, every
major cycle.

Ciao,
 Emmanuele.

--
https://www.bassi.io
[@] ebassi [@gmail.com]
_______________________________________________
gtk-devel-list mailing list
[hidden email]
https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Reply | Threaded
Open this post in threaded view
|

Re: First deprecate APIs and then remove them in the next major version

Christian Schoenebeck
On Mittwoch, 13. Dezember 2017 12:33:34 CET Emmanuele Bassi wrote:
> On 13 December 2017 at 12:05, Sébastien Wilmet <[hidden email]> wrote:
> > Ideally, a new major version of a library should only remove deprecated
> > APIs.
> The short answer is: that's not how library development works, unless
> you have a small enough library whose API is inconsequential, or it's
> used only by a handful of projects. GTK is neither.

The most popular application level frameworks i.e. from Apple, Microsoft, Qt,
etc. are actually all handling it as expected by application developers; that
is they usually deprecate old APIs and retain them for many years before they
eventually (if at all) remove them one day. It is rare that they remove APIs
without deprecating them first, and in such rare cases there are "usually"
profound reasons like security aspects (or -cough- "product policies").

> If we just removed deprecated API without adding any new feature,
> there would be no incentive whatsoever to port applications to a new
> major version, which will result in an untested API that we cannot
> change until the next major release cycle.

Personally I feel with him, although I can live with APIs being removed, even
without a deprecation phase. A much bigger problem that I see is when
replacement APIs are introduced which are missing features from their
predecessors. That happened with at least every major release of Gtk, and I
see this to happen with Gtk 4 again. I hope some of my patches will be
accepted to fix a couple of those issues before Gtk 4 will be officially
released.

CU
Christian
_______________________________________________
gtk-devel-list mailing list
[hidden email]
https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Reply | Threaded
Open this post in threaded view
|

Re: First deprecate APIs and then remove them in the next major version

Emmanuele Bassi
On 13 December 2017 at 16:34, Christian Schoenebeck
<[hidden email]> wrote:

> On Mittwoch, 13. Dezember 2017 12:33:34 CET Emmanuele Bassi wrote:
>> On 13 December 2017 at 12:05, Sébastien Wilmet <[hidden email]> wrote:
>> > Ideally, a new major version of a library should only remove deprecated
>> > APIs.
>> The short answer is: that's not how library development works, unless
>> you have a small enough library whose API is inconsequential, or it's
>> used only by a handful of projects. GTK is neither.
>
> The most popular application level frameworks i.e. from Apple, Microsoft, Qt,
> etc. are actually all handling it as expected by application developers; that
> is they usually deprecate old APIs and retain them for many years before they
> eventually (if at all) remove them one day. It is rare that they remove APIs
> without deprecating them first, and in such rare cases there are "usually"
> profound reasons like security aspects (or -cough- "product policies").

In short:

 - GTK supports parallel installation of different major API versions
 - symbols, types, properties, and signals deprecated in a major API
version continue to exist forever (and possibly work as well)
 - new major versions remove the deprecated API from the previous
major API version
 - application developers port their projects between major versions
at their own leisure

The API that gets removed in GTK+ 3.9x is deprecated in GTK+ 3.22 beforehand.

We are not talking about remove API inside the same major version.

Porting applications between major versions is its own effort, just
like porting an application from Windows Vista to Windows 10, or from
macOS 10.6 to 10.12.

>> If we just removed deprecated API without adding any new feature,
>> there would be no incentive whatsoever to port applications to a new
>> major version, which will result in an untested API that we cannot
>> change until the next major release cycle.
>
> Personally I feel with him, although I can live with APIs being removed, even
> without a deprecation phase. A much bigger problem that I see is when
> replacement APIs are introduced which are missing features from their
> predecessors. That happened with at least every major release of Gtk, and I
> see this to happen with Gtk 4 again. I hope some of my patches will be
> accepted to fix a couple of those issues before Gtk 4 will be officially
> released.

Not every new feature or replacement will be 1:1 with deprecated API.
We did not deprecate something because we were tired of how it's
named: we deprecated it because some things should not be done any
more, or because they won't work in a new environment, or because they
exposed some toolkit internals that make changing the toolkit without
breaking applications impossible.

Ciao,
 Emmanuele.

--
https://www.bassi.io
[@] ebassi [@gmail.com]
_______________________________________________
gtk-devel-list mailing list
[hidden email]
https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Reply | Threaded
Open this post in threaded view
|

Re: First deprecate APIs and then remove them in the next major version

Nicolas Dufresne-4
In reply to this post by Christian Schoenebeck
Le mercredi 13 décembre 2017 à 17:34 +0100, Christian Schoenebeck a
écrit :

> > On 13 December 2017 at 12:05, Sébastien Wilmet <[hidden email]> wrote:
> > > Ideally, a new major version of a library should only remove deprecated
> > > APIs.
> >
> > The short answer is: that's not how library development works, unless
> > you have a small enough library whose API is inconsequential, or it's
> > used only by a handful of projects. GTK is neither.
>
> The most popular application level frameworks i.e. from Apple, Microsoft, Qt,
> etc. are actually all handling it as expected by application developers; that
> is they usually deprecate old APIs and retain them for many years before they
> eventually (if at all) remove them one day. It is rare that they remove APIs
> without deprecating them first, and in such rare cases there are "usually"
> profound reasons like security aspects (or -cough- "product policies").
I don't think that applies to QT3/4/5 and then big jump, QML. GTK 4 is
the second major rework of GTK, it breaks stuff, and that's how we
modernize libraries. GTK3 is not going to be removed from servers when
GTK3 comes out, neither the .9 release means that stable 3.X is dead.

We did the same move with GStreamer, it's painful, but to progress,
it's needed.

Nicolas
_______________________________________________
gtk-devel-list mailing list
[hidden email]
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

signature.asc (201 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: First deprecate APIs and then remove them in the next major version

Christian Schoenebeck
In reply to this post by Emmanuele Bassi
On Mittwoch, 13. Dezember 2017 16:55:41 CET Emmanuele Bassi wrote:

>  - GTK supports parallel installation of different major API versions
>  - symbols, types, properties, and signals deprecated in a major API
> version continue to exist forever (and possibly work as well)
>  - new major versions remove the deprecated API from the previous
> major API version
>  - application developers port their projects between major versions
> at their own leisure
>
> The API that gets removed in GTK+ 3.9x is deprecated in GTK+ 3.22
> beforehand.

I think most people on this list know these things already. ;-)

> We are not talking about remove API inside the same major version.
>
> Porting applications between major versions is its own effort, just
> like porting an application from Windows Vista to Windows 10, or from
> macOS 10.6 to 10.12.

Well, but you also know that their APIs are much more long-term stable than
gtk, to a large percentage even ABI stable.

From my personal experience at least, maintaining an application on top of
gtk(mm) means more effort than mainining an application on top of any other
major application level framework. Unless you decide for your application to
stick with gtk version x, like some projects already did for such reasons as
mentioned by Sébastien.

> Not every new feature or replacement will be 1:1 with deprecated API.
> We did not deprecate something because we were tired of how it's
> named: we deprecated it because some things should not be done any

Mja, it is one thing to decide which internal things should be exposed to the
API and in which way exactly. I am fine with that. Another thing is to decide
on behalf of *all* application developers "you should no longer use such kind
of features in your app - so we removed them". The latter is something which
should clearly be avoided in a framework as much as possible.

I'm logging out from this topic now, but I definitely agree with Sébastien and
I also share the opinon that many gtk decisions gave me the impression that
they were not made from an application developer perspective.

CU
Christian
_______________________________________________
gtk-devel-list mailing list
[hidden email]
https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Reply | Threaded
Open this post in threaded view
|

Re: First deprecate APIs and then remove them in the next major version

Christian Hergert
In reply to this post by Sébastien Wilmet-2
On 12/13/2017 04:05 AM, Sébastien Wilmet wrote:
> Can I remind you that most of the biggest GTK+ apps are still using
> GTK+ 2? MonoDevelop, GIMP, Ardour, …

MonoDevelop is still Gtk2 because Novell/Xamarin/Unity3d invested, quite
literally, millions of dollars on consultants to work on the OS X port
(without much interest in paying additional money to have that work
upstream'd or ported to Gtk3). Add to that the necessity to write new
bindings around G-I for Gtk♯ 3 and you can get the idea of how they see
that as risk from a business standpoint.

Ardour could never move to Gtk3 because a number of VST plugins use Gtk2
and you cannot mix both into the same process space. DAW authors will
often cite the necessity for plugins to be in process to allow for a
large number of tracks/plugins due to context switching. (This is a
contributing factor to why many DAWs write their own UI toolkits).

As for GIMP, I think the lesson I take away is that we need to recruit
people to go do the ports for important projects rather than expect them
to track us. Red Hat has shown that this strategy works in both Firefox
and LibreOffice (which are arguably the two hardest applications to port).

-- Christian
_______________________________________________
gtk-devel-list mailing list
[hidden email]
https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Reply | Threaded
Open this post in threaded view
|

Re: First deprecate APIs and then remove them in the next major version

Sébastien Wilmet-2
In reply to this post by Emmanuele Bassi
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.

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]. It's of course much worse
if porting directly from 3.22 to 4.0.

[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.

--
Sébastien
_______________________________________________
gtk-devel-list mailing list
[hidden email]
https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Reply | Threaded
Open this post in threaded view
|

Re: First deprecate APIs and then remove them in the next major version

Sébastien Wilmet-2
In reply to this post by Christian Hergert
On Wed, Dec 13, 2017 at 03:08:46PM -0800, Christian Hergert wrote:

> On 12/13/2017 04:05 AM, Sébastien Wilmet wrote:
> > Can I remind you that most of the biggest GTK+ apps are still using
> > GTK+ 2? MonoDevelop, GIMP, Ardour, …
>
> MonoDevelop is still Gtk2 because Novell/Xamarin/Unity3d invested, quite
> literally, millions of dollars on consultants to work on the OS X port
> (without much interest in paying additional money to have that work
> upstream'd or ported to Gtk3). Add to that the necessity to write new
> bindings around G-I for Gtk♯ 3 and you can get the idea of how they see
> that as risk from a business standpoint.
>
> Ardour could never move to Gtk3 because a number of VST plugins use Gtk2
> and you cannot mix both into the same process space. DAW authors will
> often cite the necessity for plugins to be in process to allow for a
> large number of tracks/plugins due to context switching. (This is a
> contributing factor to why many DAWs write their own UI toolkits).

Thanks for that information, I was not aware of those problems.

> As for GIMP, I think the lesson I take away is that we need to recruit
> people to go do the ports for important projects rather than expect them to
> track us. Red Hat has shown that this strategy works in both Firefox and
> LibreOffice (which are arguably the two hardest applications to port).

The question is: why don't they do the port to GTK+ 3 "themselves"?
Because it's hard, you say it yourself in case of Firefox and
LibreOffice. With the GTK+ 2 -> 3 transition, there are a lot of "direct
API breaks". With GTK+ 3 -> 4, the same is happening. Lots of direct API
breaks at once, that's what makes it hard to port an application or a
higher-level library. For 10k lines of code, it's entirely feasible. For
100k lines, it's feasible by a full-time employee. For an application
the size of MonoDevelop, this is just unmanageable IMHO.

With "soft API breaks" (i.e. just removing an API that was deprecated in
a previous major version), I think this would improve a lot the
situation and would avoid to repeat the same problem as GTK+ 2 -> 3.

--
Sébastien
_______________________________________________
gtk-devel-list mailing list
[hidden email]
https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Reply | Threaded
Open this post in threaded view
|

Re: First deprecate APIs and then remove them in the next major version

Bastien Nocera
On Thu, 2017-12-14 at 19:56 +0100, Sébastien Wilmet wrote:
>
<snip>
> With "soft API breaks" (i.e. just removing an API that was deprecated
> in
> a previous major version), I think this would improve a lot the
> situation and would avoid to repeat the same problem as GTK+ 2 -> 3.

It already exists. Look at the "DISABLE_DEPRECATED" macros in the
current version of libraries, and which usually get removed in the +1
version.
_______________________________________________
gtk-devel-list mailing list
[hidden email]
https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Reply | Threaded
Open this post in threaded view
|

Re: First deprecate APIs and then remove them in the next major version

Sébastien Wilmet-2
On Thu, Dec 14, 2017 at 08:02:56PM +0100, Bastien Nocera wrote:

> On Thu, 2017-12-14 at 19:56 +0100, Sébastien Wilmet wrote:
> >
> <snip>
> > With "soft API breaks" (i.e. just removing an API that was deprecated
> > in
> > a previous major version), I think this would improve a lot the
> > situation and would avoid to repeat the same problem as GTK+ 2 -> 3.
>
> It already exists. Look at the "DISABLE_DEPRECATED" macros in the
> current version of libraries, and which usually get removed in the +1
> version.

Yes, it's a nice feature, but it doesn't solve the problem that there
are a lot of direct API breaks during GTK+ 3.9x development.

--
Sébastien
_______________________________________________
gtk-devel-list mailing list
[hidden email]
https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Reply | Threaded
Open this post in threaded view
|

Re: First deprecate APIs and then remove them in the next major version

Emmanuele Bassi
In reply to this post by Sébastien Wilmet-2
On 14 December 2017 at 18:42, Sébastien Wilmet <[hidden email]> 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
[hidden email]
https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Reply | Threaded
Open this post in threaded view
|

Re: First deprecate APIs and then remove them in the next major version

Sébastien Wilmet-2
On Thu, Dec 14, 2017 at 08:34:51PM +0000, Emmanuele Bassi wrote:

> On 14 December 2017 at 18:42, Sébastien Wilmet <[hidden email]> 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
[hidden email]
https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Reply | Threaded
Open this post in threaded view
|

Re: First deprecate APIs and then remove them in the next major version

Debarshi Ray-2
In reply to this post by Christian Hergert
On Wed, Dec 13, 2017 at 03:08:46PM -0800, Christian Hergert wrote:
> As for GIMP, I think the lesson I take away is that we need to recruit
> people to go do the ports for important projects rather than expect them
> to track us. Red Hat has shown that this strategy works in both Firefox
> and LibreOffice (which are arguably the two hardest applications to port).

Unlike Firefox, LibreOffice or MonoDevelop, GIMP has practically no
corporate investment. It's done entirely by volunteers and the
combined resources barely amount to one full-time developer.

Secondly, GIMP comes with its own programming interface [1]. So, a
port from GTK+ 2 to 3 implies an API break. It is probably similar to
Ardour in this aspect.

Long story short, GIMP 3.0 will be a port to GTK+ 3 (or 4), but that
will happen once 2.10 is finished in a few weeks or months.

[1] https://developer.gimp.org/api/2.0/libgimp/
_______________________________________________
gtk-devel-list mailing list
[hidden email]
https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Reply | Threaded
Open this post in threaded view
|

Re: First deprecate APIs and then remove them in the next major version

Matthias Clasen-2
In reply to this post by Sébastien Wilmet-2
On Thu, Dec 14, 2017 at 4:41 PM, Sébastien Wilmet <[hidden email]> 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.
 

_______________________________________________
gtk-devel-list mailing list
[hidden email]
https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Reply | Threaded
Open this post in threaded view
|

Re: First deprecate APIs and then remove them in the next major version

Sébastien Wilmet-2
On Fri, Dec 15, 2017 at 11:10:46AM -0500, Matthias Clasen wrote:

> 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.

About the cost of compatibility layers, it reminds me an economics
principle with game theory and cooperation, for example with the
prisoner's dilemma:
https://en.wikipedia.org/wiki/Prisoner%27s_dilemma#Strategy_for_the_prisoner's_dilemma

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.

--
Sébastien
_______________________________________________
gtk-devel-list mailing list
[hidden email]
https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Reply | Threaded
Open this post in threaded view
|

Re: First deprecate APIs and then remove them in the next major version

Christian Schoenebeck
On Samstag, 16. Dezember 2017 12:05:03 CET Sébastien Wilmet wrote:
> On Fri, Dec 15, 2017 at 11:10:46AM -0500, Matthias Clasen wrote:
> > I know this may sound harsh, but: If you want things to work differently,
> > send patches.

In theory. In practice you send patches and then you get a response like "hmm,
not sure about that, I would like to have it differently", and that without an
actual suggestion how to do that "differently".

Like you said, if you want things differently, send your patches. But then as
a patch sender you have the same expectation: you don't like the patch, make a
better suggestion! You don't have a better suggestion or at least an adequate
feedback? Ok, then apply the patch and simply add FIXME comment(s) at your own
discretion and maybe one day somebody replaces it with a better solution.

Just one example, gtk3 (yes 3, not even 4) is currently completely unusable on
Mac, so I sent a patch to fix this:

        https://bugzilla.gnome.org/show_bug.cgi?id=791174

I know my patch is suboptimal, but to make this clear: it does not address a
minor bug, this bug is a real show stopper on Mac, and this change is purely
gtk internal. Of course it is not a clean solution, but there is no reason to
simply apply this patch (at a bare minimum at least to the gtk3/stable branch)
with a FIXME comment for now so that people on Mac can finally start using gtk3
at all.

> > 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.
>
> About the cost of compatibility layers, it reminds me an economics
> principle with game theory and cooperation, for example with the
> prisoner's dilemma:
> https://en.wikipedia.org/wiki/Prisoner%27s_dilemma#Strategy_for_the_prisoner
> 's_dilemma
>
> 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".

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.

CU
Christian
_______________________________________________
gtk-devel-list mailing list
[hidden email]
https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Reply | Threaded
Open this post in threaded view
|

Re: First deprecate APIs and then remove them in the next major version

Matthias Clasen-2
On Sat, Dec 16, 2017 at 9:12 AM, Christian Schoenebeck <[hidden email]> 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.

_______________________________________________
gtk-devel-list mailing list
[hidden email]
https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Reply | Threaded
Open this post in threaded view
|

Re: First deprecate APIs and then remove them in the next major version

Daniel Kasak-4
In reply to this post by Christian Schoenebeck
On Sun, Dec 17, 2017 at 1:12 AM, Christian Schoenebeck <[hidden email]> wrote:
On Samstag, 16. Dezember 2017 12:05:03 CET Sébastien Wilmet wrote:
> On Fri, Dec 15, 2017 at 11:10:46AM -0500, Matthias Clasen wrote:
> > I know this may sound harsh, but: If you want things to work differently,
> > send patches.

In theory. In practice you send patches and then you get a response like "hmm,
not sure about that, I would like to have it differently", and that without an
actual suggestion how to do that "differently".

Like you said, if you want things differently, send your patches. But then as
a patch sender you have the same expectation: you don't like the patch, make a
better suggestion! You don't have a better suggestion or at least an adequate
feedback? Ok, then apply the patch and simply add FIXME comment(s) at your own
discretion and maybe one day somebody replaces it with a better solution.

Just one example, gtk3 (yes 3, not even 4) is currently completely unusable on
Mac, so I sent a patch to fix this:

        https://bugzilla.gnome.org/show_bug.cgi?id=791174

I know my patch is suboptimal, but to make this clear: it does not address a
minor bug, this bug is a real show stopper on Mac, and this change is purely
gtk internal. Of course it is not a clean solution, but there is no reason to
simply apply this patch (at a bare minimum at least to the gtk3/stable branch)
with a FIXME comment for now so that people on Mac can finally start using gtk3
at all.

I really have to agree. One of my bugs I raised in 2004 - which involves data loss - is still open. I submitted a patch ( which was difficult at the time - I only dabble in C when I absolutely have to ) which received very little feedback, and the bug has rotted since. I believe it exists in gtk+ versions 2 and 3, but I removed support for GtkComboBoxEntry widgets from all my code when porting to version 3 to avoid the issue entirely.

"Send a patch" only goes so far. If patches don't get reviewed, or don't get sufficient feedback, and never get accepted, what's the point in sending patches?

Dan

_______________________________________________
gtk-devel-list mailing list
[hidden email]
https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Reply | Threaded
Open this post in threaded view
|

Re: First deprecate APIs and then remove them in the next major version

Emmanuele Bassi
On 17 December 2017 at 23:14, Daniel Kasak <[hidden email]> wrote:

>> Just one example, gtk3 (yes 3, not even 4) is currently completely
>> unusable on
>> Mac, so I sent a patch to fix this:
>>
>>         https://bugzilla.gnome.org/show_bug.cgi?id=791174
>>
>> I know my patch is suboptimal, but to make this clear: it does not address
>> a
>> minor bug, this bug is a real show stopper on Mac, and this change is
>> purely
>> gtk internal. Of course it is not a clean solution, but there is no reason
>> to
>> simply apply this patch (at a bare minimum at least to the gtk3/stable
>> branch)
>> with a FIXME comment for now so that people on Mac can finally start using
>> gtk3
>> at all.
>
>
> I really have to agree. One of my bugs I raised in 2004 - which involves
> data loss - is still open. I submitted a patch ( which was difficult at the
> time - I only dabble in C when I absolutely have to ) which received very
> little feedback, and the bug has rotted since.

Yes, everyone has their own pet bug where they submitted a patch and
waited for feedback, as if GTK doesn't have ~3000 issues open at any
given time, and a constant stream of bugmail.

It would be *great* if we could review all incoming patches; sadly, we
either do that, or we spend time actually developing the toolkit.

Plus, if you have a patch lying in bugzilla for *13* years and you
never bothered to actually poke people about it, then I don't think
it'll ever get bumped up in terms of priority on the list of things to
do.

> "Send a patch" only goes so far. If patches don't get reviewed, or don't get
> sufficient feedback, and never get accepted, what's the point in sending
> patches?

Your role doesn't terminate at sending a patch.

It's your bug, your patch, and your responsibility for bringing it up
to the people *volunteering* to work on GTK. If you have a patch that
is languishing in Bugzilla, join the #gtk+ IRC channel on
irc.gnome.org, or send an email to gtk-devel-list.

Otherwise, you get exactly what you paid for.

Ciao,
 Emmanuele.

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