> > 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 _______________________________________________ pygtk mailing list pygtk@daa.com.au http://www.daa.com.au/mailman/listinfo/pygtk Read the PyGTK FAQ: http://faq.pygtk.org/