Re: [pygtk] PyGtk and gtk-3.0 compatibility

[Alberto Ruiz <aruiz gnome org>]

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.

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