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

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.


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]