Re: PyGtk and gtk-3.0 compatibility

[John Stowers <john stowers lists gmail com>]

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
>