Re: [pygtk] PyGtk and gtk-3.0 compatibility

[Tomeu Vizoso <tomeu sugarlabs org>]

On Thu, Jul 8, 2010 at 16:19, Gerald Britton <gerald britton gmail com> wrote:
> On Thu, Jul 8, 2010 at 4:03 AM, Tomeu Vizoso <tomeu sugarlabs org> wrote:
>> On Mon, Jul 5, 2010 at 15:48, John Stowers <john stowers lists 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   pygtk daa com au
>>> http://www.daa.com.au/mailman/listinfo/pygtk
>>> Read the PyGTK FAQ: http://faq.pygtk.org/
>>>
>> _______________________________________________
>> pygtk mailing list   pygtk daa com au
>> http://www.daa.com.au/mailman/listinfo/pygtk
>> Read the PyGTK FAQ: http://faq.pygtk.org/
>>
>
>
>
> --
> Gerald Britton
>