On 22 May 2016 at 18:30, Michael Catanzaro <mcatanz...@gnome.org> wrote: > GNOME Shell extensions have this same problem. Firefox did better, but > in the end it too had to give up; you've probably heard all its > extensions need to be rewritten now.
Right; in one sense plugins let us prototype some new things easily (that are headed upstream) and it also lets us support some of the "enterprise" funk that big companies are asking us for in RHEL. Compiling a plugin is a one line gcc command rather than building half of GNOME in jhbuild which makes it easier to get started. > It's not that external plugins in general are bad, it's that allowing > them access to your application's internals is bad. 100% agree. To compile an out of tree plugin you have to define the alarmingly-obnoxious-and-long I_KNOW_THE_GNOME_SOFTWARE_API_IS_SUBJECT_TO_CHANGE and we really restrict the API that plugins can use; I've been carefully splitting out functionality into -private.h headers recently that plugins have no business meddling with and I'm quite happy with the minimal API surface I'm presenting so far. I guess my statement about out-of-tree plugins being a bad idea in the introduction perhaps isn't strong enough, I can certainly ramp up this if you think it would help. From my point of view if I break your external plugin due to an API change in the core you should have pushed your changes upstream sooner. Richard _______________________________________________ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list