GNOME Bugzilla – Bug 632113
Migrate from PyGTK to PyGObject introspection-based bindings
Last modified: 2012-09-02 04:18:02 UTC
Grep'ing for pygtk-2.0 it seems that this module uses the stable bindings
provided by PyGTK.
As it is unlikely that anybody will continue maintaining these stable bindings,
applications using PyGTK should be ported to using the dynamic Python bindings
provided by PyGObject (now that PyGI has been merged into PyGObject).
The feedback on migration provided by application maintainers will also help
PyGObject to improve its dynamic bindings.
Please see http://live.gnome.org/GnomeGoals/PythonIntrospectionPorting for more
information and guidelines.
For getting involved in the development of pygobject there is a mailing list at
There is also the #python IRC channel on irc.gimp.net.
Javier, your message is not quite correct - I will continue to maintain PyGTK and support the GTK+-2.X API.
John: Via static bindings?
Yeah, I'm maintaining the PyGTK static bindings now.
No new gtk+-3.0 features will be added to PyGTK but for the last (2.22) release I finished updating the PyGTK bindings so they now cover the complete 2.X API.
In future I will be making bug fix releases and ensuring that PyGTK continues to work against gtk+-2.X.
By the way, you will have to wait for goocanvas to add support of gobject introspection, this is a work in progress.
(In reply to comment #4)
> By the way, you will have to wait for goocanvas to add support of gobject
> introspection, this is a work in progress.
Check the dependent bug 648015 , I'm working on the goocanvas introspection ATM. I expect it actually works well enough for Pitivi to use it now.
Still in the plans, but that'll take a while. We might end up using the compatibility layer for gtk, unless we manage switch everything that was mentioned in http://jeff.ecchi.ca/blog/2012/02/28/y-u-no-gtk3-yet/ in one go. I guess it will depend on the time at which we get around to tackling this.
I started to work on the porting using gtkcompat here: https://github.com/thiblahute/Pitivi/tree/gtkcompat
It is supposed to be a transitionnal state but I think this way we could start porting PiTiVi to GI and thus Gst-1.0 without making it completely incompatible with the current code we have.
There is obviuouly quite a lot of work to do still, and this branch was more about checking how possible it was for us to use the compatibility layer, I think the result is quite good, and we should follow on that branch.
Done with the 120+ commits between 2488645ecfd5c and 99d23dbf528d.