[PyKDE] Re: embedding python widgets in C++ app

David Boddie david at boddie.org.uk
Sun Jan 28 20:11:19 GMT 2007

On Sat, 27 Jan 2007 14:12:49 -0900, Patrick Stinson wrote:

> I mashed up a simple and dry reference for this procedure. I'm still
> editing it a little...
> http://www.patrickkidd.com/pk/trac/wiki/EmbeddedPythonWidgets

It looks good - you added support for specifying a parent widget so that
you don't have to worry about references once the Python object goes out
of scope, and I think that's the best way to manage object ownership.

Some points:

 * You create a Python long object to pass in to the factory function
   add it to the arguments tuple. Later, you decrement the reference
   count of this object, but I think this is the wrong thing to do
   because PyTuple_SetItem apparently "steals" a reference to the


 * You could probably just return the widget object itself from the factory
   function and extract the widget pointer from it, either by accessing the
   sipWrapper's internal structure or, since you are including the
   sipQtGuiWidget.h file, by calling sipConvertToInstance() with the
   sipClass_QWidget as the type to convert to:


   In an experiment of mine, I transferred ownership of the widget to
   the parent, using sip.transferto() before returning the widget object
   back to C++.

 * I'm not sure how to deal with the parentless widget case. It's possible
   to return the widget object back to C++ but, without a parent to take
   ownership (since the object is no longer in any Python scope), it seems
   like you would end up leaking references to objects. That's why it seems
   like a good idea to have a factory object that can be created in this way
   (leaking just one reference) that can then be used to create widgets.
   Unfortunately, in order for it to exist on the C++ side, it looks like you
   would need to use an existing wrapped type for this purpose.

 * It would be good if you could attach some kind of license to the code so
   that it's clear to people what their options are when re-using it. Some of
   the original code was licensed under the GPL by Jim Bublitz and myself.
   However, since it's only a short piece of code, I would be happy to let
   people use it under more permissive licenses, as long as Jim agrees.
   After all, I'm sure many people have written much the same code on a
   number of different occasions.

   However, it would be good if any improvements can be used by the
   community, particularly for supporting plugin integration in Qt 4 and
   KDE 4.


More information about the PyQt mailing list