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

[John Stowers <john stowers lists gmail com>]

> > 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.

Cool.

> 
> > 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.

Ok, so the syntax for these remains the same?

> 
>  > * 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

That is encouraging then.

> 
> > * 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.

AIUI the python plugin loader for libpeas is PyGI based, which links to
gtk-3.0, which means there is no upgrade path for those plugins except
to port to PyGI (i.e. import gtk brings in gtk-2.0, only one runtime per
process allowed...)

This does not seem developer friendly to me.

> 
> 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.

This seems a little soft. Please do not take offence, but can this
please be treated with similar stability guarantees and respect as gtk+
- if your commit breaks backwards compatibility with no warning then it
will be reverted.

Regards,

John