Re: GNOME 3.0 in March 2011

[John Stowers <john stowers lists gmail com>]

> >
> > Would you consider supporting non pygobject-g-i (i.e. traditional)
> > python plugins in libpeas if I finish the pygtk-3.0 stuff [1]?
> 
> The thing is, I don't really want to write pygtk-based bindings. The 
> goal is to allow application writers to *not* write bindings, and those 
> who use libpeas already use pygi anyway so how useful would it be?
> 
> Also, pygtk is supposed to be dying...

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 am not just concern trolling here, I regularly help people on the
pygtk list and I would estimate that very few people actually know what
is going on. Hell, take an example I just saw in google reader this
morning [2], that developer is going to wake up the morning after their
distro release and see his plugin fail to work - the most I expect he
will see is a note in the release notes that says "Rhythmbox now uses
libpeas for plugins". We need to think of a better backwards
compatibility story, or add a big heading to the top of [1] that says
"If you wrote a python plugin for GEdit/totem/Rhythmbox, it will not
work in GNOME 3.0 (and GNOME 2.32)"

I offer a third option. Plugins add 'pygtk.require(3.0)' [3] to their
code and libpeas support loading legacy plugins.

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?

Regards,

John

[1] http://live.gnome.org/Gedit/Plugins#third_party
[2]
http://www.omgubuntu.co.uk/2010/07/fullscreen-rhythmbox-plug-in-your.html
[3] actually if pygtk.available(3.0): pygtk.require(3.0). I will
probably make it print a big "YOU SHOULD BE USING PYGOBJECT GI" to
stdout/stderr.