On Sun, Nov 7, 2010 at 2:24 PM, John Stowers <john.stowers.li...@gmail.com> wrote: > I don't know what I plan to do. Thoughts appreciated.
This seems like a fairly cut-and-dry situation to me. PyGTK is officially considered "legacy support" only, all efforts should be placed on making PyGObject as good as it can possibly be. The idea of a backwards-compatible PyGTK-3 was noble, but if it's not possible to maintain compatibility, then don't waste your time. Just consider the most likely use-case for a backwards-incompatible PyGTK3: Alice is an application developer who has written a non-trivial PyGTK2 application. She is informed that PyGTK2 is no longer supported and that she'll need to port her app to stay current. She looks at the available options and sees that she can either port to PyGTK3 or PyGObject. She doesn't really know what PyGObject is, but based on the name alone determines that PyGTK3 is the successor to PyGTK2. She begins porting her app to PyGTK3 and eventually completes her port successfully. Now what? She just spent a bunch of time porting to an evolutionary dead-end and is left with something that is still old, broken, and unsupported. Now she has to spend a bunch MORE effort porting to PyGObject. I think the community as a whole would be FAR better served by having not just better PyGObject code, but better documentation for PyGObject (including porting HOWTOs). In my humble opinion, that is ;-) -- http://exolucere.ca _______________________________________________ pygtk mailing list pygtk@daa.com.au http://www.daa.com.au/mailman/listinfo/pygtk Read the PyGTK FAQ: http://faq.pygtk.org/