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

[Tomeu Vizoso <tomeu vizoso gmail com>]

On Mon, Jul 5, 2010 at 15:22, John Stowers <john stowers lists gmail com> wrote:
>
>> > 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?

Yup, otherwise it's a bug.

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

I wanted to port Sugar completely to introspection and have gotten it
running at a couple of points in the past, but my other work derailed
that effort. Sugar is quite big and complex and I expect to do the
move for real at the start of our next release cycle, in about 3-4
months.

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

What could we do to make the move less painful?

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

I do take seriously compatibility with existing software, at the very
least until the next 1-2 major releases.

Given the little (relative) involvement of application authors in
upstream PyGObject, having such a policy may be the only practical way
to keep compatibility, but it's a bit sad that this could hold
development back and may discourage contributors that want to help
with the new stuff.

Cheers,

Tomeu

> Regards,
>
> John
>
>
>