Re: PyGtk and gtk-3.0 compatibility

[Murray Cumming <murrayc murrayc com>]

On Sat, 2010-07-17 at 12:50 +1200, John Stowers wrote:
> 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

What's the status of this now? Is there every likely to be a pygtk
release for GTK+ 3?

-- 
murrayc murrayc com
www.murrayc.com
www.openismus.com