[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:       Sébastien Wilmet <swilmet () gnome ! org>
Date:       2017-12-14 18:56:25
Message-ID: 20171214185625.GB1669 () gamma ! lan
[Download RAW message or body]

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