> > > > 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. _______________________________________________ desktop-devel-list mailing list [email protected] http://mail.gnome.org/mailman/listinfo/desktop-devel-list
