On 1/28/07, David Boddie <[EMAIL PROTECTED]> 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
function.
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 [email protected]
http://mats.imk.fraunhofer.de/mailman/listinfo/pykde
--
Patrick Kidd Stinson
http://www.patrickkidd.com/
http://pkaudio.sourceforge.net/
http://pksampler.sourceforge.net/
_______________________________________________
PyKDE mailing list [email protected]
http://mats.imk.fraunhofer.de/mailman/listinfo/pykde
