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? -- murr...@murrayc.com www.murrayc.com www.openismus.com _______________________________________________ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
