On Mon, Jul 5, 2010 at 15:22, John Stowers <john.stowers.li...@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 > > > _______________________________________________ pygtk mailing list pygtk@daa.com.au http://www.daa.com.au/mailman/listinfo/pygtk Read the PyGTK FAQ: http://faq.pygtk.org/
