Re: GNOME 3.0 in March 2011

> >
> > 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?



[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

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]