On Fri, 2010-07-30 at 00:23 +0200, Steve Frécinaux wrote: > On 07/30/2010 12:13 AM, John Stowers wrote: > > I have no objection to that. My problem is that in the space of one > > minor release, *every* python plugin for a gtk application (e.g [1]) has > > skipped this 'dying' phase and move straight to 'dead'. That is not a > > nice backwards compatibility story for python developers. > > > > I offer a third option. Plugins add 'pygtk.require(3.0)' [3] to their > > code and libpeas support loading legacy plugins. > > It's not as simple: you can't use pygtk and pygi at the same time in the > same program.
Is that still true if PyGtk+friends is built against Gtk-3.0 etc? That is not my understanding. > So you would have to choose between running pygi-based > plugins or legacy pygtk ones. And those legacy plugins would require > some changes anyway: Gedit.WindowActivatable is not the same as > gedit.Plugin... > > The only fix would be to allow running both at the same time, for > instance by reimplementing pygtk as a compatibility layer over pygi, but > then there would be no need for libpeas to support pygtk explicitely. > > > You suggest that you do not want to maintain def files any more. Fair > > enough, but I suspect that the C-api between the minor releases of these > > apps would be retained (as is expected of C-apis). If the C-api has been > > retained then what is the maintenance burden of keeping the defs file > > around which describe this API? > > Actually, I don't want to *write* those, and especially the required > overrides. But the defs and the overrides, had already been written (for < 2.32?). I am not suggesting adding defs and overrides of new API. John _______________________________________________ desktop-devel-list mailing list [email protected] http://mail.gnome.org/mailman/listinfo/desktop-devel-list
