Re: [pygtk] PyGtk and gtk-3.0 compatibility

[Tomeu Vizoso <tomeu sugarlabs org>]

On Thu, Jul 8, 2010 at 18:22, Alberto Ruiz <aruiz gnome org> wrote:
> Hey Tomeu,
>
> Is there a plan to update the reference documentation for PyGtk 3.0?
>
> I see this as a major problem at the moment as anyone googling is
> gonna hit the 2.0 reference and end up in a pretty strange situation
> of stuff just not working for no apparent reason.

On the introspection side of things, work is going on in g-i to
generate a single set of documentation that will include the calling
conventions for C, JS, Python, Vala, etc.

As hinted in an earlier message, pygobject includes a set of
"overrides" that expand the API provided by g-i for compatibility with
the static bindings. The idea is that this will make easier to port
existing software and will make existing documentation useful for a
longer time.

Regards,

Tomeu

> 2010/7/8 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
>>>
>> _______________________________________________
>> gtk-devel-list mailing list
>> gtk-devel-list gnome org
>> http://mail.gnome.org/mailman/listinfo/gtk-devel-list
>>
>
>
>
> --
> Un saludo,
> Alberto Ruiz
>