[Cairo] another set of Python bindings

[James Henstridge]

On 12/09/03 20:22, Maarten Breddels wrote:

>> From my experiences, SWIG is suboptimal for wrapping "object 
>>oriented 
>>C" APIs.  It leaves you with a direct procedural binding of the C 
>>functions, and then you need to build something on top to get 
>>a binding 
>>more appropriate to the language.  In addition, you would 
>>    
>>
>
>Yup, that's the way I'd like to see it
>
>  
>
>>probably need 
>>_different_ SIWG .i files for each of those languages, since 
>>the .i file 
>>generally has language specific annotations.
>>    
>>
>
>Not anymore, newstyle typemaps are in the following format:
>	%typemap(python, out) char*  {
>		$result = PyString_FromStringAndSize($1, arg1);
>	} 
>So you can write typemaps for any language, and generate the Python and 
>Ruby binding using 1 SWIG file
>
Okay.  I am still not sure this would lead to a maintainable binding, 
given that you will need a bunch of code sitting on top of the swig 
generated binding for both languages.

>>It would be good to work towards a single binding though.  My main 
>>requirement for such a binding is that I can use it as a 
>>dependency for 
>>pygtk at some point in the future (when GTK depends on Cairo).  Being 
>>usable with from PyGTK programs right now would be nice too.
>>    
>>
>
>Well, I'd rather keep the bindings simple, and not putting any binding
>to
>GTK, PIL or wxWindows in the cairobinding itself. It makes the Cairo
>binding clean,
>and without a lot of dependencies. If you do it in Python, you can
>provide for 
>example, a Python module which uses wxPython, but doesn't require it. It
>will
>simple give an import error in Python, and not a missing dll/lib when 
>linking or importing.
>For example, a Java binding doesn't really want binding to all of these,
>just 
>some CairoPanel on which to dump the raw image.
>
The prototype binding I did actually contains two C extensions.  One is 
the plain Cairo binding, only linking against libcairo and friends.  The 
other extension builds on top of the first and pygtk, allowing you to 
create Cairo surfaces from various GDK primitives.  The first binding is 
usable without GDK, and would probably even work with your Windows port 
of Cairo (it doesn't wrap any of the primitives used for creation of 
surfaces).

>Btw, I believe your binding doesn't wrap cairo_surface_create_for_image,
>
>I do it by using a Python string ("\0" * height * stride) as a buffer,
>I don't know if this is valid, since I believe Python strings are
>immutable.
>  
>
I have a function to create a surface from a GdkPixbuf, which uses 
cairo_surface_create_for_image().  Python strings are immutable, so 
allowing the user to create a surface from one doesn't sound correct.  
It looks like the buffer interface would be the one to use:
    http://www.python.org/doc/2.3/api/abstract-buffer.html

In particular, the PyObject_AsWriteBuffer() function.  From what I can 
tell, this would allow you to create a buffer from an array object (from 
the array module), or even multi-dimensional arrays from the Numeric 
package.

For Numeric Python arrays, we could easily infer the height, width and 
row stride from the dimensions of the array.  I have similar code in 
PyGTK that allows the user to create a Numeric Python array that points 
at the pixel data in a GdkPixbuf.

James.

-- 
Email: james at daa.com.au
WWW:   http://www.daa.com.au/~james/