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

[Christian Schoenebeck]

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 interested
> in being able to deal with.

Well, I know the old opinion about this issue. In practice one process per 
plugin actually scales quite well on modern hardware. Even if you might have a 
very large amount of plugin instances, usually these are just instances of 
some very few plugins in your project though.

In the end you can still make this behavior configurable per plugin. So you 
might setup your DAW project to use certain plugins in-process (i.e. various 
insert effects) and certain complex / problematic plugins (i.e. virtual 
instruments and master effects) process separated.

On the mid/long term I am pretty sure all DAW apps will be going this way.

On Sonntag, 24. Dezember 2017 16:24:28 CET Robin Gareus wrote:
> Process-separation requires a context-switch which is very expensive and
> does not scale [1]. There are no plans to add this to Ardour.

Yes, I am aware about the context switch of course.

The point here is that you don't necessarily need a context switch for each 
track, or even for each individual plugin instance applied to a track. So the 
math outlined on that maling list reference is quite pessimistic. Depending on 
your precise DAW project setup/routing you might even be fine with only two 
context switches per audio cycle for all instances of one specific plugin.

Anyway, I was just curious what Ardour's plans were about this issue. I'm out 
now. Merry Xmas holidays everyone!

CU
Christian
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

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

[Robin Gareus]

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 system
abstraction.

>> however, the issues that have been mentioned before regarding host/plugin
>> toolkit interactions did make their (and users') lives miserable, hence the
>> switch.​
> 
> 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?
> 

Process-separation requires a context-switch which is very expensive and
does not scale [1]. There are no plans to add this to Ardour.

ciao,
robin

[1]
http://lists.ardour.org/pipermail/ardour-users-ardour.org/2015-August/027373.html
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

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

[Paul Davis]

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, the issues that have been mentioned before regarding host/plugin
> > toolkit interactions did make their (and users') lives miserable, hence
> the
> > switch.​
>
> 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 interested
in being able to deal with.
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

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

[Christian Schoenebeck]

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 users') lives miserable, hence the
> switch.​

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?

CU
Christian
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

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

[Tomasz Gąsior]

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

___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

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

[Emmanuele Bassi]

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. 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]
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

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

[Christian Schoenebeck]

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 to do, so let's
> > start
> > removing everything we don't like anymore".
> 
> Maybe give a concrete example of an api that we could have 'preserved with
> no effort"
> and yet removed out of folly ? I would be interested.

Of course I can give you examples. But I wonder if it makes sense to continue 
the discussion. From the responses I see here it looks pretty clear to me what 
the next answers will be.

But since you asked for it, here are some of the things that immediately come 
to my mind which should not have been dropped in my opinion:

* UI manager
* stock IDs
* gtk actions

but also some individual common short hand functions like 
gtk_widget_modify_bg() for instance.

> To me this reads like a misunderstanding.

I am aware about the release cycles and their implied procedures of gtk and 
co, really. I can't remember if we already used gtk 1, but it was definitely 
since gtk 2 that we were using it as GUI framework and are maintining our code 
base since then up to including the latest gtk 4 development branch.

> Moving an application from GTK3 to GTK4 means porting work. But you do it
> only once,
> and you don't retain GTK3 compatibility. At least, that is not what the
> GTK+ team
> recommends you should do.

What I tried to explain is that what you and other people here see as "normal" 
release cycle procedures for gtk, is no longer a normal procedure for any 
other major application level framework out there nowadays. For most of 
today's application developers, API stability is *the* most important criteria 
to pick a framework solution, far more important than its feature set.

Just one example: if you have an application on top of Qt, the last major 
porting work you had to do was from Qt3 to Qt4. That was more than 12 years 
ago. From Qt4 to Qt5 there were almost no API break at all, so little apps 
just had to (more or less) recompile for Qt 5, and bigger apps only required a 
very limited amount of effort to port them to Qt 5. As a consequence even huge 
Qt application projects are still following the latest Qt major version today, 
which is hardly feasible for large gtk apps from an economical point of view.

The API breaks of native frameworks on Mac and Windows are even less in that 
time range. Chances are that even your compiled binaries from back then would 
run today.

> If you want to stick with GTK3, you are more than welcome to do so for
> years to come.

Of course, and they stop there.

As a consequence the popularity of gtk shrinks, there are less contributions, 
and so on.

On Montag, 18. Dezember 2017 00:16:34 CET Emmanuele Bassi wrote: 
> It would be *great* if we could review all incoming patches; sadly, we
> either do that, or we spend time actually developing the toolkit.
> 
> Plus, if you have a patch lying in bugzilla for *13* years and you
> never bothered to actually poke people about it, then I don't think
> it'll ever get bumped up in terms of priority on the list of things to
> do.
[snip]
> 
> Your role doesn't terminate at sending a patch.
> 
> It's your bug, your patch, and your responsibility for bringing it up
> to the people *volunteering* to work on GTK. If you have a patch that
> is languishing in Bugzilla, join the #gtk+ IRC channel on
> irc.gnome.org, or send an email to gtk-devel-list.

Usually maintainers decide which issues are major ones, and which ones are 
getting priority. That's not the job of the reporter.

Many of the most talented developers and engineers I know are very humble/shy 
and would immediately give up on that since they avoid annoying people.

Obviously with open source projects the common rules are a bit different than 
with proprietary, pure commercial ones. But even with open source projects 
there is usually a differentiation between somebody who just files a bug 
report, and somebody who actually also comes up with a patch to fix that issue.

But to be fair, I wonder if not even the usage of Bugzilla is one of the 
reasons why the management of patch submissions is currently going wrong with 
gtk. I mean Bugzilla is known for its potential to simply create a huge black 
hole.

Fact is, due to the way patches are currently handled for gtk; you send a 
couple patches and then you give up.

CU
Christian
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

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

[Daniel Kasak]

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 looking for more volunteers, have a good
think about this.

Just recently another bug has been marked as a duplicate of this one. I get
the feeling if I just continue to ping the bug, or the list, people would
tell me to pull my head in because it's not scratching their itch or
whatever. I only brought it up in the context of someone else saying there
are issues getting patches reviewed and applied.

Regarding IRC - I've never used it because it doesn't save history, so I
have to keep an IRC client open 24/7 just to see people's responses - and
the people I'm waiting on are invariably in a different timezone. If you
have a viable product, submitting a bug to their bug tracking systems and
pinging a couple of times should be sufficient - and I note what's been
said above regarding there only being 1 full-time developer on the product.
Redirecting people to IRC doesn't make less work for anyone - it makes
more. Anyway, I did email the gtk-devel-list - from memory - though
admittedly it was 13 years ago, as you mentioned.

> Otherwise, you get exactly what you paid for.

Oh, I had that one coming. Thankyou.

Dan

On Mon, Dec 18, 2017 at 11:16 AM, Emmanuele Bassi  wrote:

> 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 suboptimal, but to make this clear: it does not
> address
> >> a
> >> minor bug, this bug is a real show stopper on Mac, and this change is
> >> purely
> >> gtk internal. Of course it is not a clean solution, but there is no
> reason
> >> to
> >> simply apply this patch (at a bare minimum at least to the gtk3/stable
> >> branch)
> >> with a FIXME comment for now so that people on Mac can finally start
> using
> >> gtk3
> >> at all.
> >
> >
> > I really have to agree. One of my bugs I raised in 2004 - which involves
> > data loss - is still open. I submitted a patch ( which was difficult at
> the
> > time - I only dabble in C when I absolutely have to ) which received very
> > little feedback, and the bug has rotted since.
>
> Yes, everyone has their own pet bug where they submitted a patch and
> waited for feedback, as if GTK doesn't have ~3000 issues open at any
> given time, and a constant stream of bugmail.
>
> It would be *great* if we could review all incoming patches; sadly, we
> either do that, or we spend time actually developing the toolkit.
>
> Plus, if you have a patch lying in bugzilla for *13* years and you
> never bothered to actually poke people about it, then I don't think
> it'll ever get bumped up in terms of priority on the list of things to
> do.
>
> > "Send a patch" only goes so far. If patches don't get reviewed, or don't
> get
> > sufficient feedback, and never get accepted, what's the point in sending
> > patches?
>
> Your role doesn't terminate at sending a patch.
>
> It's your bug, your patch, and your responsibility for bringing it up
> to the people *volunteering* to work on GTK. If you have a patch that
> is languishing in Bugzilla, join the #gtk+ IRC channel on
> irc.gnome.org, or send an email to gtk-devel-list.
>
> Otherwise, you get exactly what you paid for.
>
> Ciao,
>  Emmanuele.
>
> --
> https://www.bassi.io
> [@] ebassi [@gmail.com]
>
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

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

[Emmanuele Bassi]

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 suboptimal, but to make this clear: it does not address
>> a
>> minor bug, this bug is a real show stopper on Mac, and this change is
>> purely
>> gtk internal. Of course it is not a clean solution, but there is no reason
>> to
>> simply apply this patch (at a bare minimum at least to the gtk3/stable
>> branch)
>> with a FIXME comment for now so that people on Mac can finally start using
>> gtk3
>> at all.
>
>
> I really have to agree. One of my bugs I raised in 2004 - which involves
> data loss - is still open. I submitted a patch ( which was difficult at the
> time - I only dabble in C when I absolutely have to ) which received very
> little feedback, and the bug has rotted since.

Yes, everyone has their own pet bug where they submitted a patch and
waited for feedback, as if GTK doesn't have ~3000 issues open at any
given time, and a constant stream of bugmail.

It would be *great* if we could review all incoming patches; sadly, we
either do that, or we spend time actually developing the toolkit.

Plus, if you have a patch lying in bugzilla for *13* years and you
never bothered to actually poke people about it, then I don't think
it'll ever get bumped up in terms of priority on the list of things to
do.

> "Send a patch" only goes so far. If patches don't get reviewed, or don't get
> sufficient feedback, and never get accepted, what's the point in sending
> patches?

Your role doesn't terminate at sending a patch.

It's your bug, your patch, and your responsibility for bringing it up
to the people *volunteering* to work on GTK. If you have a patch that
is languishing in Bugzilla, join the #gtk+ IRC channel on
irc.gnome.org, or send an email to gtk-devel-list.

Otherwise, you get exactly what you paid for.

Ciao,
 Emmanuele.

-- 
https://www.bassi.io
[@] ebassi [@gmail.com]
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

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

[Daniel Kasak]

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 work
> differently,
> > > send patches.
>
> In theory. In practice you send patches and then you get a response like
> "hmm,
> not sure about that, I would like to have it differently", and that
> without an
> actual suggestion how to do that "differently".
>
> Like you said, if you want things differently, send your patches. But then
> as
> a patch sender you have the same expectation: you don't like the patch,
> make a
> better suggestion! You don't have a better suggestion or at least an
> adequate
> feedback? Ok, then apply the patch and simply add FIXME comment(s) at your
> own
> discretion and maybe one day somebody replaces it with a better solution.
>
> 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 suboptimal, but to make this clear: it does not address
> a
> minor bug, this bug is a real show stopper on Mac, and this change is
> purely
> gtk internal. Of course it is not a clean solution, but there is no reason
> to
> simply apply this patch (at a bare minimum at least to the gtk3/stable
> branch)
> with a FIXME comment for now so that people on Mac can finally start using
> gtk3
> at all.
>

I really have to agree. One of my bugs I raised in 2004 - which involves
data loss - is still open. I submitted a patch ( which was difficult at the
time - I only dabble in C when I absolutely have to ) which received very
little feedback, and the bug has rotted since. I believe it exists in gtk+
versions 2 and 3, but I removed support for GtkComboBoxEntry widgets from
all my code when porting to version 3 to avoid the issue entirely.

"Send a patch" only goes so far. If patches don't get reviewed, or don't
get sufficient feedback, and never get accepted, what's the point in
sending patches?

Dan
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

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

[Matthias Clasen]

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 applications.
>
> This is always the common argument "retaining old APIs means more work".
> But
> if you look at what APIs had been removed in gtk (and glib and co) in the
> past, most of them could have been preserved with no or little effort on
> library level.
>
> 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 to do, so let's
> start
> removing everything we don't like anymore".
>

Maybe give a concrete example of an api that we could have 'preserved with
no effort"
and yet removed out of folly ? I would be interested.


> Addressing major library changes on application level often means *much*
> more
> effort, because as application you don't necessarily have access to library
> internal things nor can you make certain presumptions. Plus not only one
> gtk
> app project has to do that gtk version compatibility work, all gtk app
> projects need to do them.  If you calculate how many man hours are wasted
> on
> all these applications, just for retaining compatiblity with the latest
> major
> gtk version, then you probably might see that the trash can decisions are
> currently made far too easily on library level.
>

To me this reads like a misunderstanding.

Moving an application from GTK3 to GTK4 means porting work. But you do it
only once,
and you don't retain GTK3 compatibility. At least, that is not what the
GTK+ team
recommends you should do.

If you want to stick with GTK3, you are more than welcome to do so for
years to come.
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

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

[Christian Schoenebeck]

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 like "hmm, 
not sure about that, I would like to have it differently", and that without an 
actual suggestion how to do that "differently".

Like you said, if you want things differently, send your patches. But then as 
a patch sender you have the same expectation: you don't like the patch, make a 
better suggestion! You don't have a better suggestion or at least an adequate 
feedback? Ok, then apply the patch and simply add FIXME comment(s) at your own 
discretion and maybe one day somebody replaces it with a better solution.

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 suboptimal, but to make this clear: it does not address a 
minor bug, this bug is a real show stopper on Mac, and this change is purely 
gtk internal. Of course it is not a clean solution, but there is no reason to 
simply apply this patch (at a bare minimum at least to the gtk3/stable branch) 
with a FIXME comment for now so that people on Mac can finally start using gtk3 
at all.

> > Maintaining compatibility layers costs and constantly gets in the way of
> > large-scale
> > refactorings like the ones that are happening in gtk 3.9x now.
> > 
> > Note that we haven't really asked application developers to port to the
> > current 3.9x releases
> > yet, because they are still in flux.
> 
> About the cost of compatibility layers, it reminds me an economics
> principle with game theory and cooperation, for example with the
> prisoner's dilemma:
> https://en.wikipedia.org/wiki/Prisoner%27s_dilemma#Strategy_for_the_prisoner
> 's_dilemma
> 
> 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 applications.

This is always the common argument "retaining old APIs means more work". But 
if you look at what APIs had been removed in gtk (and glib and co) in the 
past, most of them could have been preserved with no or little effort on 
library level.

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 to do, so let's start 
removing everything we don't like anymore".

Addressing major library changes on application level often means *much* more 
effort, because as application you don't necessarily have access to library 
internal things nor can you make certain presumptions. Plus not only one gtk 
app project has to do that gtk version compatibility work, all gtk app 
projects need to do them.  If you calculate how many man hours are wasted on 
all these applications, just for retaining compatiblity with the latest major 
gtk version, then you probably might see that the trash can decisions are 
currently made far too easily on library level.

CU
Christian
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

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

[Sébastien Wilmet]

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
> which gets payed to work fulltime on GTK+.
> 
> Maintaining compatibility layers costs and constantly gets in the way of
> large-scale
> refactorings like the ones that are happening in gtk 3.9x now.
> 
> Note that we haven't really asked application developers to port to the
> current 3.9x releases
> yet, because they are still in flux.

About the cost of compatibility layers, it reminds me an economics
principle with game theory and cooperation, for example with the
prisoner's dilemma:
https://en.wikipedia.org/wiki/Prisoner%27s_dilemma#Strategy_for_the_prisoner's_dilemma

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 applications.

--
Sébastien
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

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

[Matthias Clasen]

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 in
> 3.9x+2 (see my comment below).
>
> Of course if GtkClipboard didn't work anymore, then it needed to be
> removed. Or maybe it was possible to port GtkClipboard to the new GDK
> API, but this would have been more work for the GTK developers. It all
> depends if you want to provide a smooth experience to port apps.
>
>
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
which gets payed to work fulltime on GTK+.

Maintaining compatibility layers costs and constantly gets in the way of
large-scale
refactorings like the ones that are happening in gtk 3.9x now.

Note that we haven't really asked application developers to port to the
current 3.9x releases
yet, because they are still in flux.
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

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

[Debarshi Ray]

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 LibreOffice (which are arguably the two hardest applications to port).

Unlike Firefox, LibreOffice or MonoDevelop, GIMP has practically no
corporate investment. It's done entirely by volunteers and the
combined resources barely amount to one full-time developer.

Secondly, GIMP comes with its own programming interface [1]. So, a
port from GTK+ 2 to 3 implies an API break. It is probably similar to
Ardour in this aspect.

Long story short, GIMP 3.0 will be a port to GTK+ 3 (or 4), but that
will happen once 2.10 is finished in a few weeks or months.

[1] https://developer.gimp.org/api/2.0/libgimp/
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

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

[Sébastien Wilmet]

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 clipboard is now implemented in GDK. GtkClipboard is not deprecated
> > in GTK+ 3.22, and the new API is not available in GDK 3.22.
> 
> The new API just landed; and, yes: it's hard to deprecate the API in
> this case, given that the new API has been moved down one level in the
> hierarchy.

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 in
3.9x+2 (see my comment below).

Of course if GtkClipboard didn't work anymore, then it needed to be
removed. Or maybe it was possible to port GtkClipboard to the new GDK
API, but this would have been more work for the GTK developers. It all
depends if you want to provide a smooth experience to port apps.

> Doing this work in 5 years, for GTK+ 5.0,
> would not have been any easier for anybody.

I don't understand why you say that. Each semi-stable 3.9x version can
be seen as a new major version, since it's possible to break the API. So
an API can be marked as deprecated in 3.92 and then removed in 3.94.
Instead of doing a direct API break. This would make it easier to port
applications.

--
Sébastien
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

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

[Emmanuele Bassi]

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:
> https://git.gnome.org/browse/gtk+/commit/?id=2d5c82b4ecbe6ff534a1b9476080e409742daa39
> "gtk: Remove GtkClipboard"
>
> The clipboard is now implemented in GDK. GtkClipboard is not deprecated
> in GTK+ 3.22, and the new API is not available in GDK 3.22.

The new API just landed; and, yes: it's hard to deprecate the API in
this case, given that the new API has been moved down one level in the
hierarchy.

This is also why we could not do this during the 3.x API cycle,
without incurring into a lot of regressions or potential breakage.

> I think Benjamin has done a great work with the new implementation. Just
> a little problem: it's what I call a "direct API break", applications or
> higher-level libraries will need to be ported from GTK+ 3.92 to 3.94
> with a big API delta, so it will result in one huge commit/branch
> untestable until all the code is ported [1].

That's what we said would happen during the 9x development cycle: no
API stability between 9x and 9x+2. We were very much upfront about the
API stability.

> It's of course much worse
> if porting directly from 3.22 to 4.0.

And we understand that. Doing this work in 5 years, for GTK+ 5.0,
would not have been any easier for anybody.

> [1] What I would recommend is to copy custom widgets/containers (if they
> are self-contained) out-of-tree, and port them individually, with a
> small GUI test program for each, so that they can be tested outside the
> whole application.

That would not help at all for the GtkClipboard case, and that would
not help with the new rendering API.

I'm sorry about the pain in porting, but this is what 2.5 years of
development are for.

Ciao,
 Emmanuele.

-- 
https://www.bassi.io
[@] ebassi [@gmail.com]
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

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

[Sébastien Wilmet]

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 and would avoid to repeat the same problem as GTK+ 2 -> 3.
> 
> It already exists. Look at the "DISABLE_DEPRECATED" macros in the
> current version of libraries, and which usually get removed in the +1
> version.

Yes, it's a nice feature, but it doesn't solve the problem that there
are a lot of direct API breaks during GTK+ 3.9x development.

--
Sébastien
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

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

[Bastien Nocera]

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. Look at the "DISABLE_DEPRECATED" macros in the
current version of libraries, and which usually get removed in the +1
version.
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

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

[Sébastien Wilmet]

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

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

[Sébastien Wilmet]

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"

The clipboard is now implemented in GDK. GtkClipboard is not deprecated
in GTK+ 3.22, and the new API is not available in GDK 3.22.

I think Benjamin has done a great work with the new implementation. Just
a little problem: it's what I call a "direct API break", applications or
higher-level libraries will need to be ported from GTK+ 3.92 to 3.94
with a big API delta, so it will result in one huge commit/branch
untestable until all the code is ported [1]. It's of course much worse
if porting directly from 3.22 to 4.0.

[1] What I would recommend is to copy custom widgets/containers (if they
are self-contained) out-of-tree, and port them individually, with a
small GUI test program for each, so that they can be tested outside the
whole application.

--
Sébastien
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

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

[Christian Hergert]

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).


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).


-- Christian
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

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

[Christian Schoenebeck]

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 remove the deprecated API from the previous
> major API version
>  - application developers port their projects between major versions
> at their own leisure
> 
> The API that gets removed in GTK+ 3.9x is deprecated in GTK+ 3.22
> beforehand.

I think most people on this list know these things already. ;-)

> We are not talking about remove API inside the same major version.
> 
> Porting applications between major versions is its own effort, just
> like porting an application from Windows Vista to Windows 10, or from
> macOS 10.6 to 10.12.

Well, but you also know that their APIs are much more long-term stable than 
gtk, to a large percentage even ABI stable.

>From my personal experience at least, maintaining an application on top of 
gtk(mm) means more effort than mainining an application on top of any other 
major application level framework. Unless you decide for your application to 
stick with gtk version x, like some projects already did for such reasons as 
mentioned by Sébastien.

> Not every new feature or replacement will be 1:1 with deprecated API.
> We did not deprecate something because we were tired of how it's
> named: we deprecated it because some things should not be done any

Mja, it is one thing to decide which internal things should be exposed to the 
API and in which way exactly. I am fine with that. Another thing is to decide 
on behalf of *all* application developers "you should no longer use such kind 
of features in your app - so we removed them". The latter is something which 
should clearly be avoided in a framework as much as possible.

I'm logging out from this topic now, but I definitely agree with Sébastien and 
I also share the opinon that many gtk decisions gave me the impression that 
they were not made from an application developer perspective.

CU
Christian
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

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

[Nicolas Dufresne]

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 development works, unless
> > you have a small enough library whose API is inconsequential, or it's
> > used only by a handful of projects. GTK is neither.
> 
> The most popular application level frameworks i.e. from Apple, Microsoft, Qt, 
> etc. are actually all handling it as expected by application developers; that 
> is they usually deprecate old APIs and retain them for many years before they 
> eventually (if at all) remove them one day. It is rare that they remove APIs 
> without deprecating them first, and in such rare cases there are "usually" 
> profound reasons like security aspects (or -cough- "product policies").

I don't think that applies to QT3/4/5 and then big jump, QML. GTK 4 is
the second major rework of GTK, it breaks stuff, and that's how we
modernize libraries. GTK3 is not going to be removed from servers when
GTK3 comes out, neither the .9 release means that stable 3.X is dead.

We did the same move with GStreamer, it's painful, but to progress,
it's needed.

Nicolas

signature.asc
Description: This is a digitally signed message part
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

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

[Emmanuele Bassi]

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 remove deprecated
>> > APIs.
>> The short answer is: that's not how library development works, unless
>> you have a small enough library whose API is inconsequential, or it's
>> used only by a handful of projects. GTK is neither.
>
> The most popular application level frameworks i.e. from Apple, Microsoft, Qt,
> etc. are actually all handling it as expected by application developers; that
> is they usually deprecate old APIs and retain them for many years before they
> eventually (if at all) remove them one day. It is rare that they remove APIs
> without deprecating them first, and in such rare cases there are "usually"
> profound reasons like security aspects (or -cough- "product policies").

In short:

 - 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 remove the deprecated API from the previous
major API version
 - application developers port their projects between major versions
at their own leisure

The API that gets removed in GTK+ 3.9x is deprecated in GTK+ 3.22 beforehand.

We are not talking about remove API inside the same major version.

Porting applications between major versions is its own effort, just
like porting an application from Windows Vista to Windows 10, or from
macOS 10.6 to 10.12.

>> If we just removed deprecated API without adding any new feature,
>> there would be no incentive whatsoever to port applications to a new
>> major version, which will result in an untested API that we cannot
>> change until the next major release cycle.
>
> Personally I feel with him, although I can live with APIs being removed, even
> without a deprecation phase. A much bigger problem that I see is when
> replacement APIs are introduced which are missing features from their
> predecessors. That happened with at least every major release of Gtk, and I
> see this to happen with Gtk 4 again. I hope some of my patches will be
> accepted to fix a couple of those issues before Gtk 4 will be officially
> released.

Not every new feature or replacement will be 1:1 with deprecated API.
We did not deprecate something because we were tired of how it's
named: we deprecated it because some things should not be done any
more, or because they won't work in a new environment, or because they
exposed some toolkit internals that make changing the toolkit without
breaking applications impossible.

Ciao,
 Emmanuele.

-- 
https://www.bassi.io
[@] ebassi [@gmail.com]
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

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

[Christian Schoenebeck]

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, unless
> you have a small enough library whose API is inconsequential, or it's
> used only by a handful of projects. GTK is neither.

The most popular application level frameworks i.e. from Apple, Microsoft, Qt, 
etc. are actually all handling it as expected by application developers; that 
is they usually deprecate old APIs and retain them for many years before they 
eventually (if at all) remove them one day. It is rare that they remove APIs 
without deprecating them first, and in such rare cases there are "usually" 
profound reasons like security aspects (or -cough- "product policies").

> If we just removed deprecated API without adding any new feature,
> there would be no incentive whatsoever to port applications to a new
> major version, which will result in an untested API that we cannot
> change until the next major release cycle.

Personally I feel with him, although I can live with APIs being removed, even 
without a deprecation phase. A much bigger problem that I see is when 
replacement APIs are introduced which are missing features from their 
predecessors. That happened with at least every major release of Gtk, and I 
see this to happen with Gtk 4 again. I hope some of my patches will be 
accepted to fix a couple of those issues before Gtk 4 will be officially 
released.

CU
Christian
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

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

[Emmanuele Bassi]

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 with sealed data structures and without deprecated API.

The short answer is: that's not how library development works, unless
you have a small enough library whose API is inconsequential, or it's
used only by a handful of projects. GTK is neither.

If we just removed deprecated API without adding any new feature,
there would be no incentive whatsoever to port applications to a new
major version, which will result in an untested API that we cannot
change until the next major release cycle.

That's why we released the 9x snapshots; to give us, and application
developers, time to iterate over the API.

The problem is that we're trying to fix almost two decaded of hacks
and cruft piled on top of each other, and any new feature comes with
its own set of removals.

> So, that's it, I think when GTK+ 4.0 will be released, if it is still
> developed in the same way, developers will have a really bad surprise
> when trying to port their code.

The reason why we're doing the 9x snapshots — the reason we change the
whole release management process and model — is because we will *not*
be developing 4.x (and 5.x, and 6.x) the same way we developed 3.x.

The 9x snapshots are the first cycles of 3.x, writ large. We give up
API compatibility during that period in order to have a firmer n.0
release, and later minor cycles, until we open the tree for the n+1
development.

Yes: the delta between 3.x and 4.x is going to be large — at least, if
you're implementing widgets. It's not something we expect this to
happen with every major release; we don't really expect to change the
way we render everything, or to change the input subsystem, every
major cycle.

Ciao,
 Emmanuele.

-- 
https://www.bassi.io
[@] ebassi [@gmail.com]
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list