On Tue, 2010-07-06 at 01:48 +1200, John Stowers 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].
This has reached a reasonable state of working, I have run the same python applications against a GSEALED G_DISABLE_DEPRECATED branch of 2.21 and against master (although for that you will also need this branch [0]) If you are interested in playing * Check out the gtk-3.0 branches of PyGObject and PyGtk [1][2] * Build against a Gtk 2.21.x release with the appropriate GSEAL and DISABLE_DEPRECATED CFLAGS The remaining work is * When needed, fix the override files to not call deprecated functions * If an object has beer wrapped with the (fields (...)) attribute then you need to either 1) Add a (getter-funcname "foo") or (getter-propname "bar") attribute to he appropriate defs file 2) Remove the field wrapping (or possible override), which will break compatibility Behind the scenes, a modified PyGObject codegen is needed because of how field access on GObjects (ie GtkWidget.window) is now handled. Access is now delegated to either a getter function (ie gtk_widget_get_window) or to a GObject property (ie g_object_get(widget, "window", &window)) depending on whether you added the getter-funcname of getter-propname to the defs file. To see remaining fields that need to be emulated grep for FIXME-FIELD in the generated code, or watch for DepreciationError runtime warnings. So depending on how many fields can be annotated in this way, and how the GDK sealing / GDKDevice cleanup goes, I am confident that with a little luck and some work, that PyGtk apps should be able to run against gtk-3.0 with no code changes (providing you were not using very old deprecated stuff, and that fields are now accessible with accessor functions). John [0] http://github.com/nzjrs/pygtk/tree/build-against-gtk-3.0 [1] http://git.gnome.org/browse/pygobject/log/?h=gtk-3.0 [2] http://git.gnome.org/browse/pygtk/log/?h=gtk-3.0 p.s. Branches will likely be rebased in future > > 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. > > 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/