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

On Sonntag, 24. Dezember 2017 10:26:48 CET Paul Davis wrote: > > The trend among DAW apps is going towards process separation for plugins > > (one > > process for all instances of a plugin). No plans for that in Ardour yet? > > ​It doesn't scale. ​Certainly not to the session size that we're

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

On 12/24/2017 04:01 PM, Christian Schoenebeck wrote: > On Samstag, 23. Dezember 2017 10:47:08 CET Paul Davis wrote: >> ​actually, my impression from interactions with the author is that GTK >> didn't make their life miserable at all. It was main gdk in that context. A basic window and event

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

On Sun, Dec 24, 2017 at 10:01 AM, Christian Schoenebeck < schoeneb...@linuxsampler.org> wrote: > On Samstag, 23. Dezember 2017 10:47:08 CET Paul Davis wrote: > > ​actually, my impression from interactions with the author is that GTK > > didn't make their life miserable at all. > > > > however,

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

On Samstag, 23. Dezember 2017 10:47:08 CET Paul Davis wrote: > ​actually, my impression from interactions with the author is that GTK > didn't make their life miserable at all. > > however, the issues that have been mentioned before regarding host/plugin > toolkit interactions did make their (and

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

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

On 23 December 2017 at 13:47, Salvatore De Paolis wrote: > On Wed, 13 Dec 2017 15:08:46 -0800 > Christian Hergert 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.

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

On Samstag, 16. Dezember 2017 14:17:11 CET Matthias Clasen wrote: > > I mean to me it looks like nobody even considered in the past to keep old > > APIs > > at all. Currently it is just a common rule "ok, we are now on the next > > major > > version branch, we are now safe to do whatever we want

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

Yeah, I poked originally. See: https://bugzilla.gnome.org/show_bug.cgi?id=156017#c3 https://bugzilla.gnome.org/show_bug.cgi?id=156017#c5 https://bugzilla.gnome.org/show_bug.cgi?id=156017#c6 Other people commented and submitted further patches after that. After that, I just gave up. If you're

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

On 17 December 2017 at 23:14, Daniel Kasak wrote: >> Just one example, gtk3 (yes 3, not even 4) is currently completely >> unusable on >> Mac, so I sent a patch to fix this: >> >> https://bugzilla.gnome.org/show_bug.cgi?id=791174 >> >> I know my patch is

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

On Sun, Dec 17, 2017 at 1:12 AM, Christian Schoenebeck < schoeneb...@linuxsampler.org> wrote: > On Samstag, 16. Dezember 2017 12:05:03 CET Sébastien Wilmet wrote: > > On Fri, Dec 15, 2017 at 11:10:46AM -0500, Matthias Clasen wrote: > > > I know this may sound harsh, but: If you want things to

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

On Sat, Dec 16, 2017 at 9:12 AM, Christian Schoenebeck < schoeneb...@linuxsampler.org> wrote: > > > With cooperation and compatibility layers in GTK, GTK would move forward > > less quickly, but it would maybe yield a better outcome globally when > > taking into account higher-level libraries and

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

On Samstag, 16. Dezember 2017 12:05:03 CET Sébastien Wilmet wrote: > On Fri, Dec 15, 2017 at 11:10:46AM -0500, Matthias Clasen wrote: > > I know this may sound harsh, but: If you want things to work differently, > > send patches. In theory. In practice you send patches and then you get a response

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

On Fri, Dec 15, 2017 at 11:10:46AM -0500, Matthias Clasen wrote: > I know this may sound harsh, but: If you want things to work differently, > send patches. > Patches to the migration guide are welcome too. > > The bulk of the work done on GTK4 so far has been done by 3 or 4 people, > only one of

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

On Thu, Dec 14, 2017 at 4:41 PM, Sébastien Wilmet wrote: > > > GDK, GSK and GTK are now part of the same *.so library. If GtkClipboard > still worked fine just before the commit that removed it, it would have > been possible to first deprecate GtkClipboard and then removing it

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: > 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

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

On Thu, Dec 14, 2017 at 08:34:51PM +, Emmanuele Bassi wrote: > On 14 December 2017 at 18:42, Sébastien Wilmet wrote: > > A recent example: > > https://git.gnome.org/browse/gtk+/commit/?id=2d5c82b4ecbe6ff534a1b9476080e409742daa39 > > "gtk: Remove GtkClipboard" > > > > The

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

On 14 December 2017 at 18:42, Sébastien Wilmet wrote: > On Wed, Dec 13, 2017 at 04:55:41PM +, Emmanuele Bassi wrote: >> The API that gets removed in GTK+ 3.9x is deprecated in GTK+ 3.22 beforehand. > > No, that's not true. > > A recent example: >

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

On Thu, Dec 14, 2017 at 08:02:56PM +0100, Bastien Nocera wrote: > On Thu, 2017-12-14 at 19:56 +0100, Sébastien Wilmet wrote: > > > > > 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

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

On Thu, 2017-12-14 at 19:56 +0100, Sébastien Wilmet wrote: > > 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. It already exists.

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

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

On Wed, Dec 13, 2017 at 04:55:41PM +, Emmanuele Bassi wrote: > The API that gets removed in GTK+ 3.9x is deprecated in GTK+ 3.22 beforehand. No, that's not true. A recent example: https://git.gnome.org/browse/gtk+/commit/?id=2d5c82b4ecbe6ff534a1b9476080e409742daa39 "gtk: Remove GtkClipboard"

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

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

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

On Mittwoch, 13. Dezember 2017 16:55:41 CET Emmanuele Bassi wrote: > - GTK supports parallel installation of different major API versions > - symbols, types, properties, and signals deprecated in a major API > version continue to exist forever (and possibly work as well) > - new major versions

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

Le mercredi 13 décembre 2017 à 17:34 +0100, Christian Schoenebeck a écrit : > > On 13 December 2017 at 12:05, Sébastien Wilmet wrote: > > > Ideally, a new major version of a library should only remove deprecated > > > APIs. > > > > The short answer is: that's not how library

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

On 13 December 2017 at 16:34, Christian Schoenebeck wrote: > On Mittwoch, 13. Dezember 2017 12:33:34 CET Emmanuele Bassi wrote: >> On 13 December 2017 at 12:05, Sébastien Wilmet wrote: >> > Ideally, a new major version of a library should only

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

On Mittwoch, 13. Dezember 2017 12:33:34 CET Emmanuele Bassi wrote: > On 13 December 2017 at 12:05, Sébastien Wilmet wrote: > > Ideally, a new major version of a library should only remove deprecated > > APIs. > The short answer is: that's not how library development works,

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

On 13 December 2017 at 12:05, Sébastien Wilmet wrote: > Ideally, a new major version of a library should only remove deprecated APIs. I'm having major flashbacks from the same discussions we had at Gran Canaria, when we planned 3.0 — with people asking for releasing 3.0 only

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

Hi, I'm a bit worried about how GTK+ 4 is developed. It seems that there will be a lot of API breaks that will require to adapt the code at once. Ideally, a new major version of a library should only remove deprecated APIs. It's how a library should be developed, in case the developers want to