GNOME Bugzilla – Bug 626224
Migrate from PyGTK to PyGObject introspection-based bindings
Last modified: 2011-04-14 19:59:04 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. ./eog/configure.ac: pygtk-2.0 >= $PYGTK_REQUIRED],
Created attachment 167387 [details] [review] Add the base modules dir Not sure if this is really needed, need to ask Steve first
Created attachment 167388 [details] [review] Add a python plugin I am bad at python, so take this as a proof of concept only
btw, I didn't take much time to remove the leftover stuff from configure.ac nor the unneeded source files, but will do it soonish. For now, this is enough for giving initial testing to this stuff.
Seems that I missed one patch..
Created attachment 167413 [details] [review] Load the Eog namespace from a private directory For now, this is done by adding the private directory to the search path. For whatever reason, g_irepository_require_private() doesn't work for me. This is enough to have python plugins working already
Created attachment 167414 [details] [review] Add the base modules dir Not sure if this is really needed, need to ask Steve first
Created attachment 167415 [details] [review] Add a python plugin I am bad at python, so take this as a proof of concept only
Review of attachment 167413 [details] [review]: I needed this one for bug 626091. commit f984f253e50e842b7c58b41593954553798f3f95 Author: Claudio Saavedra <> Date: Mon Aug 9 01:15:17 2010 +0300 Load the Eog namespace from a private directory For now, this is done by adding the private directory to the search path. For whatever reason, g_irepository_require_private() doesn't work for me. This is enough to have python plugins working already https://bugzilla.gnome.org/show_bug.cgi?id=626224
Comment on attachment 167414 [details] [review] Add the base modules dir "base-module-dir" is not supported anymore in libpeas-0.7.
I tried to check the python plugin tonight. But I am kinda stuck now. As soon as anything GTK-(or at least GtkWidget-)related stays out of play the plugin works (means it can print "activate" and "deactivate"). As soon as a GtkWidget (like EogWindow) comes into play eog hangs with the following output: /home/felix/.debug-chroots/jhbuild-gnome/lib64/python2.7/site-packages/gi/module.py:124: Warning: cannot register existing type `GtkWidget' g_type = info.get_g_type() /home/felix/.debug-chroots/jhbuild-gnome/lib64/python2.7/site-packages/gi/module.py:124: Warning: g_type_add_interface_static: assertion `G_TYPE_IS_INSTANTIATABLE (instance_type)' failed g_type = info.get_g_type() /home/felix/.debug-chroots/jhbuild-gnome/lib64/python2.7/site-packages/gi/module.py:124: Warning: cannot register existing type `GtkBuildable' g_type = info.get_g_type() /home/felix/.debug-chroots/jhbuild-gnome/lib64/python2.7/site-packages/gi/module.py:124: Warning: g_type_interface_add_prerequisite: assertion `G_TYPE_IS_INTERFACE (interface_type)' failed g_type = info.get_g_type() /home/felix/.debug-chroots/jhbuild-gnome/lib64/python2.7/site-packages/gi/module.py:124: Warning: g_once_init_leave: assertion `initialization_value != 0' failed g_type = info.get_g_type() /home/felix/.debug-chroots/jhbuild-gnome/lib64/python2.7/site-packages/gi/module.py:128: Warning: g_type_get_qdata: assertion `node != NULL' failed type_ = g_type.pytype Not sure where the problem here is. Could as well be my jhbuild instance being messed up.
I tried again on my notebook. The python plugin did indeed load and work there. But, the plugin instance apparently isn't destroyed when the window is closed which will make it prevent eog from quitting correctly (since it still keeps a ref to the window).
[Removing 3.0 target as this is not a hard blocker, but a nice to have]
So, python do work now although you have to be awesomely careful when using the given window handle to clear the use up afterwards to avoid refcount hangs. Do we actually require the example python plugin in our releases or would it be sufficient to use it to update the corresponding wiki page (http://live.gnome.org/EyeOfGnome/Plugins) and possibly use the python plugins from the eog-plugins package as an additional reference point on how to do it?
I updated the python example plugin on the wiki to be compatible with the new API. From my understanding this is complete then. :) This problem has been fixed in our software repository. The fix has gone into the last software release. Thank you for your bug report.