On Thu, Jul 8, 2010 at 16:19, Gerald Britton <[email protected]> wrote: > On Thu, Jul 8, 2010 at 4:03 AM, Tomeu Vizoso <[email protected]> wrote: >> On Mon, Jul 5, 2010 at 15:48, John Stowers <[email protected]> >> wrote: >>> Hi, >>> >>> First of all, PyGI and GObject introspection is the way forward. >>> >>> Now, that being said, it seems a little silly to spend all this effort >>> porting C apps in GNOME to gtk-3.0 only to see the first PyGtk app drag >>> back in the gtk-2.0 libraries with "import gtk". >>> >>> So I spent a little time trying to get PyGtk to build with GSEAL. Turns >>> out it wasn't that hard [1][2]. >>> >>> Only a few accessors were missing >>> * GtkWindow.has_user_ref_count >>> * GtkInvisible.has_user_ref_count >>> These both are used in the sink funcs, and seem to be a synonym >>> for checking the object has not been destroyed. >>> * gtk_menu_get_position_func{,_data} >>> >>> So, what is the opinion on this? Is it worth me continuing? My idea >>> would be to make *only one* PyGtk release that builds against gtk-3.0, >>> it would see no new features. >> >> Sounds like a good idea to me, given how much PyGTK application >> authors seem to lag behind platform changes. >> >> That said, I think distros should focus on moving to introspection >> because it allows them to drop maintenance of a lot of packages. But >> anything that makes this move easier for people is important. > > I've trying to get a handle on PyGI for a while now, but I'm still in > a bit of a fog.
First of all, sorry about the confusion, help is needed in properly explaining the situation, so if someone reading this is able to go through http://live.gnome.org and make it a bit more coherent, it will be a great contribution. Second, PyGI has ceased to exist after it was merged into PyGObject so it may be better to only refer to it for historical purposes. In practical terms, PyGObject has gained support for using gobject-based libraries through introspection. > I've worked on some PyGTK apps so understand that OK, > but what I'm really looking for are answers to questions like: > > 1. What problem is PyGI trying to solve? It adds the possibility to call gobject-based libraries without having to generate/write, build, package, maintain and install specific bindings for that library. > 2. What advantage will I see by using PyGI over PyGTK? You are able to use API that nobody has bothered to write bindings for, such as GSettings. Incidentally, your application will use less memory and will start up faster because the class wrappers are loaded lazily. One more consequence is that in order to port your application to Python 3.x or another Python implementation such as Jython you will only need to port your application code and PyGObject, and not the thousands of lines in static bindings. Last, is that the Python GNOME community can focus on improving and completing a much smaller codebase if we don't need to maintain static bindings for each library out there. We also pool resources with the other GNOME teams maintaining bindings for other languages. This has its importance because as we know critical components of Python in GNOME were having just minimal maintenance, when any at all. > 3. How do I port my application from PyGTK to PyGI? Right now, you need to change the way modules are imported (s/import gtk/from gi.repository import Gtk/) and mostly adapt to the API provided by the C libraries you use. This example script may give an idea of the transformations required: http://git.gnome.org/browse/pygobject/tree/pygi-convert.sh That said, PyGObject provides a mechanism for overriding the C API and is being used to provide an API more compatible with PyGTK. There's also the possibility to simulate the old way of importing modules with some import hook magic. As people start porting their applications, we'll know better how to make it easier. There exists the possibility that applications can be made to use introspected libraries instead of static bindings without changes, but it requires someone doing the work upstream. Note that by integrating PyGI into PyGObject we don't force you to use introspection instead of static bindings. It just gives the community a way forward that could work, given the current resources available. Hope it clarifies a bit, Tomeu >> >> Regards, >> >> Tomeu >> >>> John >>> >>> [1] http://github.com/nzjrs/pygtk/commits/gtk-3.0 >>> [2] http://github.com/nzjrs/pygobject/tree/gtk-3.0 >>> >>> _______________________________________________ >>> pygtk mailing list [email protected] >>> http://www.daa.com.au/mailman/listinfo/pygtk >>> Read the PyGTK FAQ: http://faq.pygtk.org/ >>> >> _______________________________________________ >> pygtk mailing list [email protected] >> http://www.daa.com.au/mailman/listinfo/pygtk >> Read the PyGTK FAQ: http://faq.pygtk.org/ >> > > > > -- > Gerald Britton > _______________________________________________ pygtk mailing list [email protected] http://www.daa.com.au/mailman/listinfo/pygtk Read the PyGTK FAQ: http://faq.pygtk.org/
