Re: GNOME 3.0 in March 2011

[John Stowers <john stowers lists gmail com>]

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