If you look at the code in _gdkimlibmodule.c or _gnomeuimodule.c, you will
see how I have been passing pointers to the different PyTypeObject's
defined in _gtkmodule.c. That is probably the best way to go. It only
requires a bit of code in the init routine, and you get a bit more type
safety than you would using PyCObject's.
James Henstridge.
--
Email: [EMAIL PROTECTED]
WWW: http://www.daa.com.au/~james/
On 4 Mar 1999, Ture [iso-8859-1] P�lsson wrote:
> I'm experimenting with displaying 3D models in a PyGtk DrawingArea. To
> get (re)display fast enough, I "compile" the model into a set of line
> segments that can be drawn witk GtkDrawingArea.draw_segments. The
> problem with this approach is that tens of thousands of line segments,
> represented as a list of quadruples of integers, consume a LOT of
> memory. It also takes a lot of time to build up the structure, and
> then take it apart again when the low-level pygtk code calls
> gdk_draw_segments. To get around this problem, I'd like to keep the
> line segment list as an array of GtkSegments and do the
> gdk_draw_segment call from C.
>
> However, there does not seem to be a "clean" way for a module written
> in C to get hold of (for example) the GdkWindow* for a drawing area
> created with pygtk. Of course, I could use PyGdkWindow_Get, but this
> would mean that my C code had to include header files from pygtk, and
> possibly also link with parts of pygtk, which feels a little
> uncomfortable.
>
> One way to work around this would be to add a method to the PyGdk_Foo
> types, that returns the underlying GtkFoo* wrapped in a PyCObject.
> That way, it would be possible for Python code to pass the low-level C
> objects into a module written in C that performs direct gdk calls, and
> still have the C code independent of the inner workings of pygtk. I
> have implemented this in my own copy of PyGtk; if anyone else thinks
> it's a good idea, I'll try to extract a patch from among all the
> ~-files sitting around my ~/src/ directory. :-)
>
> Another wild idea on the same theme (I haven't tested this one,
> though) is to give the PyGtk_Object class a python-callable
> constructor that takes a CObject as argument. This could be used to
> interface third-party Gtk widgets into pygtk, without having to modify
> pygtk itself.
>
> -- Ture
> To unsubscribe: echo "unsubscribe" | mail [EMAIL PROTECTED]
>
To unsubscribe: echo "unsubscribe" | mail [EMAIL PROTECTED]