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

[Tomasz Gąsior <mail tomaszgasior kao pl>]

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 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
>
> I wonder why GTK+ has not been forked yet.
>
> S.
> _______________________________________________
> gtk-devel-list mailing list
> gtk-devel-list gnome org
> https://mail.gnome.org/mailman/listinfo/gtk-devel-list