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