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