Re: First deprecate APIs and then remove them in the next major version
- From: Emmanuele Bassi <ebassi gmail com>
- To: Salvatore De Paolis <iwkse-ml gmx com>
- Cc: GTK Devel List <gtk-devel-list gnome org>
- Subject: Re: First deprecate APIs and then remove them in the next major version
- Date: Sat, 23 Dec 2017 14:06:00 +0000
On 23 December 2017 at 13:47, Salvatore De Paolis <iwkse-ml gmx com> wrote:
On Wed, 13 Dec 2017 15:08:46 -0800
Christian Hergert <christian hergert me> wrote:
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).
http://libremusicproduction.com/news/20171221-lsp-plugins-version-110-released-farewall-gtk
Unsurprisingly, considering that the whole UI is completely custom and
using a generic desktop toolkit would have made their lives miserable.
I wonder why GTK+ has not been forked yet.
I wonder why you don't keep this kind of statements for yourself; in
any case, feel free to fork GTK and figure how why nobody does that.
Ciao,
Emmanuele.
--
https://www.bassi.io
[@] ebassi [@gmail.com]
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]