Web lists-archives.com

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




Instead of forking, you can create your own patches to vanilla GTK3. :)
I like GTK-based desktops but some GNOME devs decisions are not good to me, so I created my own patches for GTK3. You can do something similar.

See  https://github.com/TomaszGasior/gtk3-mushrooms

---
Tomasz Gąsior
https://tomaszgasior.pl

W dniu 2017-12-23 14:47, Salvatore De Paolis napisał(a):
On Wed, 13 Dec 2017 15:08:46 -0800
Christian Hergert <christian@xxxxxxxxxx> 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

I wonder why GTK+ has not been forked yet.

S.
_______________________________________________
gtk-devel-list mailing list
gtk-devel-list@xxxxxxxxx
https://mail.gnome.org/mailman/listinfo/gtk-devel-list
_______________________________________________
gtk-devel-list mailing list
gtk-devel-list@xxxxxxxxx
https://mail.gnome.org/mailman/listinfo/gtk-devel-list