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. 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 py...@daa.com.au >>>> http://www.daa.com.au/mailman/listinfo/pygtk >>>> Read the PyGTK FAQ: http://faq.pygtk.org/ >>>> >>> _______________________________________________ >>> pygtk mailing list py...@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-list@gnome.org > http://mail.gnome.org/mailman/listinfo/gtk-devel-list > -- Un saludo, Alberto Ruiz _______________________________________________ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list