[PyKDE] Re: embedding python widgets in C++ app
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...
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.
* 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
More information about the PyQt