On Thu, Jul 8, 2010 at 18:22, Alberto Ruiz <ar...@gnome.org> wrote: > Hey Tomeu, > > Is there a plan to update the reference documentation for PyGtk 3.0? > > I see this as a major problem at the moment as anyone googling is > gonna hit the 2.0 reference and end up in a pretty strange situation > of stuff just not working for no apparent reason.
On the introspection side of things, work is going on in g-i to generate a single set of documentation that will include the calling conventions for C, JS, Python, Vala, etc. As hinted in an earlier message, pygobject includes a set of "overrides" that expand the API provided by g-i for compatibility with the static bindings. The idea is that this will make easier to port existing software and will make existing documentation useful for a longer time. Regards, Tomeu > 2010/7/8 Tomeu Vizoso <to...@sugarlabs.org>: >> On Thu, Jul 8, 2010 at 16:19, Gerald Britton <gerald.brit...@gmail.com> >> wrote: >>> On Thu, Jul 8, 2010 at 4:03 AM, Tomeu Vizoso <to...@sugarlabs.org> wrote: >>>> On Mon, Jul 5, 2010 at 15:48, John Stowers <john.stowers.li...@gmail.com> >>>> 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 pygtk@daa.com.au >>>>> http://www.daa.com.au/mailman/listinfo/pygtk >>>>> Read the PyGTK FAQ: http://faq.pygtk.org/ >>>>> >>>> _______________________________________________ >>>> pygtk mailing list pygtk@daa.com.au >>>> http://www.daa.com.au/mailman/listinfo/pygtk >>>> Read the PyGTK FAQ: http://faq.pygtk.org/ >>>> >>> >>> >>> >>> -- >>> Gerald Britton >>> >> _______________________________________________ >> gtk-devel-list mailing list >> gtk-devel-l...@gnome.org >> http://mail.gnome.org/mailman/listinfo/gtk-devel-list >> > > > > -- > Un saludo, > Alberto Ruiz > _______________________________________________ pygtk mailing list pygtk@daa.com.au http://www.daa.com.au/mailman/listinfo/pygtk Read the PyGTK FAQ: http://faq.pygtk.org/