PyGObject and introspection concerns (was Re: [pygtk] PyGTK 2.17 for Windows)

[Tomeu Vizoso <tomeu vizoso gmail com>]

On 07/03/2010 01:24 AM, John Stowers wrote:
> On Thu, 2010-07-01 at 15:33 +0200, Tomeu Vizoso wrote:
> > On Thu, Jul 1, 2010 at 15:13, John Stowers<john stowers lists gmail com>  wrote:
> > > On Thu, Jul 1, 2010 at 6:52 PM, Jason Heeris<jason heeris gmail com>  wrote:
> > > > I'm trying to get a PyGTK app going on a Windows XP installation. It
> > > > requires PyGTK 2.17. I have Python 2.6 and GTK 2.18 set up just fine,
> > > > but of course there's no binary installer for PyGTK 2.17. So I grabbed
> > > > the source from FTP[1], along with PyGObject, intending to build it
> > > > under MinGW.
> > > >
> > > > But it turns out I need PyGI to build PyGObject, and PyGI requires
> > > > "Python development tools" to build, and searching the web for that
> > > > problem yields nothing useful.
> > > >
> > > > So before I embark on some odyssey of pain trying to get this all to
> > > > work, my question is: is there an easier way? A binary installer for
> > > > PyGI for Windows? A binary installer for PyGTK 2.17?
> > >
> > > Hi,
> > >
> > > I have been generating the python installers for windows.
> > >
> > > It really is a shame that there was not a stable release of PyGobject
> > > and PyGtk for so long, so now we are in this situation where the last
> > > non-pygi release of PyGObject was technically an unstable one. I would
> > > not like predict we will see a PyGtk release before/around the time of
> > > the last stable Gtk+-2.0 series.
> > >
> > > This, and the fact that PyGtk has effectively been deprecated an
> > > replaced with PyGI makes me nervous.
> >
> > Which are the concerns?
>
> I just sent a mail to the python-hackers list with some of my queries.

Replying here as well as application authors will be interested.

> But my concerns are basically
>
> * What is the state of the more advanced GObject features in PyGI
>    - _gsignals_, interface implementation, signal overrides, etc?

Interface implementation and vfunc override have been implemented. 
Signals are handled by the good old code in PyGObject, but there are 
plans to extend it to use also introspection information so we can write 
a handler for a signal with GList parameters, for example. Same with 
properties. Introspection classes use a metaclass that inherits from the 
one in pygobject.

> * Are properties mapped to object.props.foo automatically?

Yup.

> * Are the PyGtk helpers like GenericTreeModel supported?

J5 did some work to implement it as an override in Python, but I don't 
know the status of it.

> * Has PyGI been used to port any non-trivial PyGtk apps yet?

There have been reports of non-trivial apps having been ported. One of 
those:

https://bugzilla.gnome.org/show_bug.cgi?id=621207#c3

> * People who wrote plugins for GEdit, Totem, or anyone copying that
>    plugin implementation are now out in the cold. The upgrade path for
>    such plugins is "rewrite them to use PyGI"

I'm not sure I understand exactly how those people are left out in the 
cold, but there are several people in the IRC channel working on plugins 
support for GEdit.

As a PyGObject maintainer, I would like to keep compatibility with older 
stable releases but my own time to devote to that is limited. I would 
like to encourage anybody interested on this to contribute by filing 
bugs, helping triage, send patches and maybe helping with maintenance in 
general.

This means that people interested in keep using the old static bindings 
should be able to do so with future releases of PyGObject, but I warn 
them that those static bindings represent lots of lines of code that 
very little people want to maintain. And of course, new APIs are not 
likely to be added.

> * Support for MacOSX and Windows

Don't know what's the status of gobject-introspection in those 
platforms, but I know that g-i is supposed to be merged in glib in the 
near future and I think it will be required that it works there.

That said, I aim for PyGObject to keep being useful when built with 
--disable-introspection.

Regards,

Tomeu

> John