GNOME Bugzilla – Bug 626231
Migrate from PyGTK to PyGObject introspection-based bindings
Last modified: 2011-03-14 16:13:10 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 help there is a mailing list at http://www.daa.com.au/mailman/listinfo/pygtk . For getting involved in the development of pygobject there is a mailing list at http://mail.gnome.org/mailman/listinfo/python-hackers-list . There is also the #python IRC channel on irc.gimp.net. ./libchamplain/configure.ac: pygtk-2.0 >= 2.12
What's the current status of PyGI? Is it "production ready" or rather experimental so far? If the latter holds won't there be any transition period in which both PyGTK and PyGI will be supported? In what time period are applications using PyGTK supposed to be migrated to PyGI?
Ahoj Jiri, > What's the current status of PyGI? Is it "production ready" or rather > experimental so far? Better you ask on the python-hackers mailing list as I'm not a Python hacker... > any transition period in which both PyGTK and PyGI will be supported? PyGTK has not seen any changes for quite a while now hence I would rather call it dead than supported. And there is not enough manpower to "support" both. > In what time period are applications using PyGTK supposed to be migrated > to PyGI? The sooner the better, as feedback and porting issues would help the GNOME Python team to improve PyGI in PyGObject...? :)
...and just when writing this I see that there is a new unstable 2.21 tarball for pygtk (but 2.22 will be the last release of PyGTK according to the wiki).
OK, thanks for the info, I was just curious about the current PyGI status. Our python bindings maintainer is Victor Godoy Poluceno so I actually hope it won't be me who has to make the changes ;-).
Created attachment 177161 [details] [review] Allow introspecting of champlain_embed_get_view
Robert, are you sure about the (transfer full)? In my opinion there should be (transfer none) because GtkChamplainEmbed is still the owner of the view. I've added --warn-all flag to the scanner and added transfers to all the necessary functions to eliminate the warnings.
I'm not at all sure. It was simply a guess based on reading GtkChamplain-0.6.gir (which I knew to work), which contained this: <method name="get_view" c:identifier="gtk_champlain_embed_get_view" version="0.4"> <doc xml:whitespace="preserve">Gets a #ChamplainView from the #GtkChamplainEmbed object.</doc> <return-value transfer-ownership="full"> <doc xml:whitespace="preserve">a #ChamplainView ready to be used</doc> <type name="Champlain.View" c:type="ChamplainView*"/> </return-value> </method> The application was functional when I did it my way, but it's also functional your way, so I don't understand the distinction. Either way, problem solved. Feel free to close this bug ;-)
(In reply to comment #6) > Robert, are you sure about the (transfer full)? In my opinion there should be > (transfer none) because GtkChamplainEmbed is still the owner of the view. If gtk_champlain_embed_get_view doesn't increase the refcount so the caller needs to unref it after use, then it should be (transfer none). See http://live.gnome.org/GObjectIntrospection/Annotations
This bug can be closed too I guess