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

Patrick Stinson patrickkidd.lists at gmail.com
Mon Jan 29 20:46:59 GMT 2007

On 1/28/07, David Boddie <david at boddie.org.uk> wrote:
> 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.

Yeah, I would only allow this code into a C++ app if I didn't have to
treat the python widgets like python widgets. All of the Py* code is
mashed into one file to keep it separate.

> 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
>    object:

right you are.

>    http://www.python.org/doc/api/refcountDetails.html#l2h-13

Yeah, I need to re-read that one. I'm procrastenating....

>  * 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:
>    http://www.riverbankcomputing.com/Docs/sip4/sipref.html#sipconverttoinstance
>    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++.

That's probably a good idea - I tried it before, but ot this to work
first. The ownership does need to be transfered to the parent since
the parent will delete it when the parent is deleted.

>  * 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.

I'm not either. I won't get to this until I actually need a parentless widget.

>  * 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

I'm confused, do you think that others will be afraid to copy my code?
My wiki is intended to get code examples for useful things on the web
for people to use however they want. This code is so short and
re-writable that I don't feel like a license even falls into scope -
especially since it's just teaching a lesson, not providing a concrete

>    the original code was licensed under the GPL by Jim Bublitz and myself.

Which part? call_function()? Everything else I re-wrote from scratch
after reading yours and other sites along with the ref docs.

>    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.

That's what my wiki is for.

> David
> _______________________________________________
> PyKDE mailing list    PyKDE at mats.imk.fraunhofer.de
> http://mats.imk.fraunhofer.de/mailman/listinfo/pykde

Patrick Kidd Stinson

More information about the PyQt mailing list